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Foreword 

This Technical Specification has been produced by the 3 rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

IP Multimedia (IM) Core Network (CN) subsystem Service Continuity (SC) provides the capability of continuing 
ongoing communication sessions with multiple media across different access networks or across different user 
equipments (UEs) under the control of the same subscriber. 

NOTE: When the communication session is transferred across different UEs, the session can be a collaborative 
session with controller and controllee UEs. In this version of the document, there can only be one 
controller UE but several controllee UEs in the collaborative session. 

The present document provides the protocol details for enabling IMS SC based on the Session Initiation protocol (SIP) 
and the Session Description Protocol (SDP) and the protocols of the 3GPP Circuit-Switched (CS) domain (e.g. CAP, 
MAP, ISUP, BICC and the NAS call control protocol for the CS access). 

The present document is applicable to User Equipment (UEs), Application Servers (AS) and MSC Servers providing 
IMS Service Continuity capabilities. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) 

and Session Description Protocol (SDP); Stage 3". 

[3] 3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[4] 3GPP TS 24.292: "IP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS); 

Stage 3". 

[5] 3GPP TS 24.216: "Communication continuity managed object". 

[6] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; Signalling flows and message 

contents". 

[7] 3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details". 

[8] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 

[9] 3GPP TS 23.237: "IP Multimedia subsystem (IMS) Service Continuity; Stage 2". 

[10] IETF RFC 3891: "The Session Initiation Protocol (SIP) "Replaces" Header". 

[II] IETF RFC 4538: "Request Authorization through Dialog Identification in the Session Initiation 
Protocol (SIP)". 

[12] 3GPP TS 23.003: "Numbering, addressing and identification". 

[13] IETF RFC 3515: "The Session Initiation Protocol (SIP) Refer Method". 
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3 Definitions and abbreviations 
3.1 Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
3GPP TR 21.905 [1]. 

Dynamic STI: An STI dynamically assigned by the SCC AS, representing the SIP dialog identifier (Call-ID header 
field and the values of tags in To and From header fields) and used for session transfer request when Gm service control 
is available. 

Inter UE Transfer SCC AS URI: A SIP URI which is a public service identity hosted by SCC AS and which is used 
in inter UE transfer procedures. 

Static STI: An STI configured in the SC UE either as a SIP URI or as an E.164 number in tel URI or SIP URI 
representation of tel URI. The static STI is used for CS-PS transfer when dynamic STI is unavailable. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [9] apply: 

Access Leg 
Remote Leg 
Target Access Leg 
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Source Access Leg 

Session Transfer Identifier (STI) 

Session Transfer Number (STN) 

Session Transfer Number for SR-VCC (STN-SR) 

Collaborative session 

Controllee UE 

Controller UE 

Inter-UE transfer 

Emergency Session Transfer Number for SR VCC(E-STN-SR) 
Correlation MSISDN 



For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.292 [4] apply: 

CS call 
CS media 



For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [12] apply: 

IP Multimedia Routing Number (IMRN) 
For the purposes of the present document, the following terms and definitions given in IETF RFC 5012 [16] apply: 

Emergency service URN 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPP TR 21.905 [1]. 



EATF 


Emergency Access Transfer Function 


E-STN-SR 


Emergency Call Session Transfer Number - Single Radio 


E-SR-VCC 


Emergency Single Radio Voice Call Continuity 


IMRN 


IP Multimedia Routing Number 


SC 


Service Continuity 


sec 


Service Centralization and Continuity 


SM 


Session Management 


SR-VCC 


Single Radio VCC 


STI 


Session Transfer Identifier 


STN 


Session Transfer Number 


STN-SR 


Session Transfer Number - Single Radio 



4 Overview of IP Multimedia (IM) Core Network (CN) 
subsystem Service Continuity 

4.1 General 

In general, SC can be divided into two concepts: 

1. providing the capability of transferring ongoing communication sessions with multiple media across different 
access networks. The main need for such continuity arises because user equipments (UEs) with multimedia 
capabilities can move across a multiplicity of different access networks; and 

2. providing the capability of transferring the communication sesions with multiple media across different UEs. 
The following procedures are provided within this document: 

- procedures for registration in IM CN subsystem are specified in clause 6; 
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- procedures for call origination are specified in clause 7; 

- procedures for call termination are specified in clause 8; 

- procedures for PS-CS access transferare specified in clause 9; 

- procedures for PS-PS access transferare specified in clause 10; 

- procedures for PS-PS access transferin conjunction with PS-CS access transferare specified in clause 11; 
procedures for PS-CS access transferfor Single Radio are specified in clause 12; 

- procedures for media adding/deleting for access transfer are specified in clause 13; 

- procedures for UE discovery for inter-UE transfer are specified in clause 14; 

- procedures for inter-UE transfer without establishment of collaborative session are specified in clause 15; 

- procedures for collaborative session establishment for inter-UE transfer are specified in clause 16; 

- procedures for media transfer within collaborative session for inter-UE transfer are specified in clause 17; 

- procedures for release of collaborative session for inter-UE transfer in clause 18; 

- procedure for media adding/deleting within collaborative session for inter-UE transfer are specified in clause 19; 
and 

- procedures for service continuity and MMTEL interactions are specified in clause 20. 

For a UE or an AS not supporting ICS procedures, PS-CS service continuity is only possible when the UE is active in a 
single full-duplex speech or speech/video session i.e. support of access transfer or inter-UE transfer with more than one 
session or with non voice media is not provided. 

4.2 Underlying network capabilities 

SC assumes the use of a number of underlying network capabilities: 

1) provision by the home network operator of SCC AS on the IM CN subsystem, as specified in 
3GPPTS 24.229 [2]; 

2) if ICS is used, the network capabilities as specified in 3GPP TS 24.292 [4]; 

4.3 URI and address assignments 

In order to support SC to a subscriber, the following URI and address assignments are assumed: 

a) in this version of the document, the SC UE for access transfer will be configured with a static STI, in accordance 
with subclause 5.11 in 3GPP TS 24.216 [5]; a static STN in accordance with subclause 5.12 in 

3GPP TS 24.216 [5] and an Inter UE Transfer SCC AS URI. The static STI is used by the SC UE to perform CS 
to PS access transfer when no dynamically assigned STI is provided to the UE over the CS domain (e.g. when 
the SC UE does not support ICS capabilities as defined in 3GPP TS 24.292 [4]). The static STN is used by the 
SC UE to perform PS to CS access transfer when no service control signalling path as specified in 
3GPP TS 24.292 [4] is available. The Inter UE Transfer SCC AS URI is used in the inter UE transfer procedures. 

b) the SC UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one or more 
public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. 
Either: 

- this public telecommunication number can be the DN (e.g. MSISDN) used in the CS domain and (in 
international form) comprise part of the implicit registration set associated with that SC UE in the IM CN 
subsystem; or 

the SCC AS can be configured to provide a functional relationship between separate numbers providing each 
of these identities in the CS domain and the IM CN subsystem, respectively. 
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5 Functional entities 

5.1 Introduction 

This clause associates the functional entities with the SC roles described in the stage 2 architecture document (see 
3GPP TS 23.237 [9]). 

5.2 User Equipment (UE) 

UE can be compliant with: 

- both the access transfer and the inter-UE transfer; 

- the access transfer; or 

- the inter-UE transfer 
in this document. 

If the SC UE supports the Controller UE procedures for IUT transfer then the SC UE may include the g.3gpp.iut- 
controller media feature tag as described in annex C in the Contact header of SIP requests and SIP responses. 

To be compliant with access transfer in this document, a UE shall implement the role of an SC UE according to 
subclause 6.2, subclause 7.2, subclause 8.2, subclause 9.2, subclause 10.2, subclause 11.2, subclause 12.2 and 
subclause 13.2. 

To be compliant with inter-UE transfer in this document, a UE shall implement the role of an SC UE: 

- by following the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN subsystem; 
and 

- according to subclause 14.2, subclause 15.2, subclause 16.2, subclause 17.2, subclause 18.2 and subclause 19.2. 

NOTE: In the inter-UE transfer, a session can be collaborative session where there are one controller UE and 

severeal controllee UEs. The controllee UE can be a legacy UE and does not have be compliant with the 
above subclauses. 

5.3 Application Server (AS) 

AS can be compliant with: 

- both the access transfer and the inter-UE transfer; 

- the access transfer; or 

- the inter-UE transfer 
in this document. 

To be compliant with access transfer in this document, an AS shall implement the role of an SCC AS according to 
subclause 6.3, subclause 7.3, subclause 8.3, subclause 9.3, subclause 10.3, subclause 11.3, subclause 12.3 and 
subclause 13.3. 

To be compliant with inter-UE transfer in this document, an AS shall implement the role of an SCC AS according to 
subclause 14.3, subclause 15.3, subclause 16.3, subclause 17.3, subclause 18.3 and subclause 19.3. 

5.4 MSC Server 

An MSC Server can be compliant with SR VCC session transfer procedures as described in this document. 
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In order to be compliant with SRVCC session transfer procedures as described in this document, an MSC server using 
SIP interface to initiate the session transfer shall provide the UA role as defined for a MGCF in annex A of 
3GPP TS 24.229 [1 1] and the role of an MSC server enhanced for SRVCC using SIP interface as described in 
subclause 12.6. 

5.5 EATF 

To be compliant with access transfer in this document, the EATF shall act as B2BUA and: 

- extract charging information as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.1.2; 

- identify the served user as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7. 1 .3A.2; 

- map the message header fields from a SIP message received in one dialog to related SIP message sent in the 
correlated dialog managed by EATF as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 

- pass signalling elements as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 

- handle P-Charging-Vector header as specified for an routeing AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; and 

- implement the role of an EATF according to subclause 7.4 and subclause 12.5. 

6 Roles for registration in the IM CN subsystem for 
service continuity 

6.1 Introduction 

Void. 

6.2 SC UE 

Prior to performing IMS registration, if the SC UE supports ICS capabilities as defined in 3GPP TS 24.292 [4], the SC 
UE shall check that IMS service continuity using ICS is enabled. An indication that SC using ICS is enabled or disabled 
can be found in the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [23]). 

The SC UE shall follow the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN 
subsystem. 

If SC using ICS is enabled then prior to making use of ICS procedures, the SC UE shall follow the procedures specified 
in 3GPP TS 24.292 [4] for registration of the ICS UE in the IM CN subsystem. 

If the SC UE supports the Controller UE procedures for IUT transfer then the SC UE shall include the g.3gpp.iut- 
controller media feature tag as described in annex C in the Contact header field of the SIP REGISTER request. 

6.3 SCC AS 

The SCC AS can obtain registration state information that it needs to implement SCC specific requirements from: 

a) any received third-party SIP REGISTER request (e.g. including information contained in the body of the third- 
party SIP REGISTER request) as specified in 3GPP TS 24.229 [2]; 

b) any received reg event package as specified in 3GPP TS 24.229 [2]; or 

c) the Sh interface as specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7]. 

NOTE: Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know 
the capabilities supported by the user registered UE(s), including the used IP-CAN(s). 
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When the SCC AS obtains the registration state information including an Correlation MSISDN using one of the above 
procedures, the SCC AS shall determine if the registration state information is associated with ongoing CS call by 
matching the Correlation MSISDN against the: 

a) tel URI in the P-Asserted-Identity header field or associated with the received IMRN when the SIP INVITE 
request was due to static STN, where the SIP INVITE request was stored according to subclause 7.3.1; or 

b) tel URI in the Request-URI when the SIP INVITE request was due to processing unregistered filter criteria, 
where the SIP INVITE request was stored according to subclause 7.3.1. 

If the registration state information is associated with an ongoing call the contents of the registration state information 
shall be bound to the ongoing CS call session identifier. 

6.4 MSC server 

If MSC server supports the MSC server assisted mid-call feature, the MSC server shall behave as an MSC server 
enhanced for ICS as specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] with following additions: 

- include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field of the SIP 
REGISTER request. 



6A Roles for General Capabilities 
6A.1 Introduction 

This clause describes the general roles for each functional entity as specified. 

6A.2 UE roles 

The SC UE may receive the operator policy via OMA Device Management, see 3GPP TS 24.216 [5]. When the SC UE 
receives the operator policy, for each session to be transferred, it shall take the operator policy into account when 
deciding to perform the following: 

- selecting the access for initiating the transfer; 

determining whether to transfer full or partial media during PS-PS transfer; or 

determining whether to add or remove media during the PS-PS transfer. 

If the SC UE is configured with the operator policy (e.g. via OMA Device Management as described in 

3GPP TS 24.216 [5]) then, for each media or group of media contained in the MediaorGroup node, the SC UE shall: 

1) restrict originating sessions and session transfer towards the access networks contained in the 
RestrictedAccessNetworkType node; 

2) consider the list of access networks contained in the PreferredAccessNetworks node in the order of priority from 
the access networks such that, when available, the highest priority access network can be used for originating 
sessions and session transfer procedures; 

3) if a new access network gets available- transfer media components to a higher priority target network than the 
current access network based on the value contained in the SC_media_transfer node value. If the 
SC_media_transfer node value is: 

"shall" the UE shall start a session transfer according to the home operator' s list of preferred access networks 
contained in the PreferredAccessNetworks node; 

"should" the UE is recommended to start session transfer according to the home operator' s list of preferred 
access networks contained in the PreferredAccessNetworks node. The UE can evaluate if session transfer is 
possible and desirable after having taken into account the Local Operating Environment Information; and 
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"may" the UE can decide whether or not to start session transfer in accordance with user preferences if 
configured in the UE. The UE can evaluate if session transfer is possible and desirable after having taken into 
account the Local Operating Environment Information. If user preferences are not configured, the UE can 
evaluate the home operator' s list of preferred access networks contained in the PreferredAccessNetworks 
node; and 

4) decide whether to keep or drop non transferable media components in the case of partial session transfer based 
on the SC_non_transferrable_media node value. 



7 Roles for call origination for service continuity 

7.1 Introduction 

This clause specifies the procedures for call origination, both where the SC UE is generating calls in the CS domain and 
where the SC UE is generating calls using the IM CN subsystem. Procedures are specified for the SC UE, the SCC AS 
and the EATF. 

7.2 SC UE 

If SC using ICS is enabled then the SC UE shall support origination of IP multimedia sessions in the IM CN subsystem 
as specified in 3GPP TS 24.229 [2]. If the SC UE supports the MSC server assisted mid-call feature, the SC UE shall 
include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field of the SIP INVITE 
request. 

The SC UE shall support origination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

The procedures for call origination where the SC UE is initiating calls using CS media are identical to that for ICS UE 
specified in 3GPP TS 24.292 [4] . 

When originating an emergency call as specified in 3 GPP TS 24.229 [2] and if the SC UE has an IMEI, then the SC UE 
shall include the instance-id media feature tag as specified in IETF RFC 5626 [22] with value based on the IMEI as 
defined in 3GPP TS 23.003 [12] in the Contact header field of the SIP INVITE request. 

7.3 SCC AS 

7.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call origination: 

- SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the origination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to originating filter criteria". It is 
assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from 
theUE. 

The SCC AS shall store the SIP INVITE requests due to static STN (as defined in subclause 9.3. 1) and the SIP INVITE 
requests due to originating filter criteria, at least until their sessions are terminated. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

7.3.2 Call origination procedures at the SCC AS 

When the SCC AS receives a SIP INVITE request due to originating filter criteria, the SCC AS shall follow the SCC 
AS roles for call origination procedures specified in 3GPP TS 24.292 [4]. 
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If: 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; 

2. the g.3gpp. mid-call media feature tag as described in annex C is included in the Contact header field of the SIP 
INVITE request due to originating filter criteria; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

NOTE: SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id header 
field and the P-Access-Network-Info header field of the SIP REGISTER request. 

then the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field 
of the SIP 2xx response to the SIP INVITE request due to originating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the g.3gpp. mid-call media feature tag as described in annex C from the SIP INVITE request due to originating 
filter criteria before forwarding the SIP INVITE request towards the remote UE. 

7.4 EATF 

7.4.1 Distinction of requests sent to the EATF 

The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call origination: 

- SIP INVITE request including a request URI that contains an emergency service URN, i.e. a service URN with a 
top-level service type of "sos" as specified in IETF RFC 5031 [17]. In the procedures below, such requests are 
known as "SIP INVITE requests due to emergency service URN". 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

7.4.2 Call origination procedures at the EATF 

When the EATF receives a SIP INVITE requests due to emergency service URN, the EATF shall store the SIP INVITE 
request until the session is terminated, anchor the session and act as specified for a routeing B2BUA in 
3GPP TS 24.229 [2], subclause 5.7.5.2.1. 



8 Roles for call termination for service continuity 

8.1 Introduction 

This clause specifies the procedures for call termination, both where the SC UE is receiving calls in the CS domain and 
where the SC UE is receiving calls using the IM CN subsystem. Procedures are specified for the SC UE and the 
SCC AS. 

8.2 SC UE 

The SC UE shall support termination of multimedia sessions in the IM CN subsystem as specified in 
3GPP TS 24.229 [2]and in 3GPP TS 24.292 [4]. If the SC UE supports the MSC server assisted mid-call feature, and 
the receiving SIP INVITE request includes media feature tag as described in annex C in the Contact header field, the SC 
UE shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field of the SIP 
2xx response to the SIP INVITE request. 

The SC UE shall support termination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 
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The procedures for call termination where the SC UE is receiving calls using CS media are identical to that for ICS UE 
roles for call termination procedures which are specified in 3GPP TS 24.292 [4]. 

8.3 SCC AS 

8.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call termination: 

- SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the termination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header field. In the 
procedures below, such requests are known as "SIP INVITE requests due to terminating filter criteria". It is 
assumed that the SCC AS is the last AS that the S-CSCF forwards the request to. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2] . 

8.3.2 Call termination procedures in the SCC AS 

When the SCC AS receives a SIP INVITE request due to terminating filter criteria, the SCC AS shall follow the SCC 
AS roles for call termination procedures specified in 3GPP TS 24.292 [4]. 

If: 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

2. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

then the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field 
of the SIP INVITE request due to terminating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the g.3gpp. mid-call media feature tag as described in annex C from the SIP 2xx response to the SIP INVITE 
request due to terminating filter criteria before forwarding the SIP 2xx response towards the remote UE. 



9 Roles for PS-CS access transfer 

9.1 Introduction 

For a UE or an AS not supporting ICS procedures, PS-CS access transfer is only possible when the UE is active in a 
single full-duplex speech or speech/video session i.e. support of session transfer with more than one sessions or with 
non voice media is not provided. 

9.2 SC UE 

9.2.1 SC UE procedures for PS to CS access transfer 

This subclause applies for IMS sessions containing speech media component only, otherwise subclause 1 1.2.1.2 applies. 

The SC UE may be engaged in one or more ongoing sessions at the time of initiating access transfer. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session 
has been sent or received. 
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If SC using ICS is enabled then if the SC UE is using Gm, then for each session to be transferred and starting with the 
active session, the SC UE shall send a SIP INVITE request to the SCC AS according to the ICS UE using Gm 
procedures for call origination as specified in 3GPP TS 24.292 [4]. The SC UE shall populate the SIP INVITE request 
as specified for PS-PS access transfer with full media transfer in subclause 10.2.1 (including the STI of the dialog to be 
transferred) with the following exceptions: 

The SC UE shall indicate in the SIP INVITE request that the speech media is using CS bearer with its 
corresponding media description. 

Upon receiving the PSI DN from the SCC AS, the SC UE shall follow the procedures for call origination for ICS 
UE using Gm in 3GPP TS 24.292 [4] to set up the CS bearer. 

If the SC UE is not using ICS capabilities and if the SC UE does not apply the MSC Server assisted mid-call feature as 
specified in subclause 9.2.1 A, then access transfer is only possible when the UE is active in a single full-duplex speech 
session. If multiple full-duplex speech sessions exist, subject to the SC_non_transferrable_media node value in the 
Communication Continuity MO (see subclause 5.27 in 3GPP TS 24.216 [5]), the SC UE shall: 

a) first initiate the release of all the ongoing full-duplex speech sessions except the session with active full-duplex 
speech component that was most recently made active and then the SC UE shall transfer the remaining ongoing 
active full-duplex speech session. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send, a CC SETUP message as specified 
in 3GPP TS 24.008 [8], to the SCC AS to set up a call over the CS domain. When sending CC SETUP message, the SC 
UE shall populate the CC SETUP message as follows: 

1) the called party BCD number information element set to the static STN; 

2) Type Of Number set to "International" and Numbering Plan Indicator set to "E. 164". in the Called Party BCD 
Number information element. 

If the SC UE receives a release message to the CC SETUP message sent, then PS-CS acccess transfer has not completed 
successfully and the call will continue in the Source Access Leg. 

9.2.1 A SC UE procedures for PS to CS access transfer with MSC server 
assisted mid-call feature 

Editor's note: it is FFS how to ensure that the UE and the MSC Server would use the same transaction identifers for 
the conferencing sessions 

The SC UE shall apply the MSC Server assisted mid-call feature when transferring the session not using ICS 
capabilities if: 

1. the SC UE supports the MSC Server assisted mid-call feature; and 

2. one of the following is true: 

A. there is at least one ongoing active full-duplex speech session and the Contact header field received during 
the establishment of the ongoing active full-duplex speech session which has been most recently made active 
includes the g.3gpp. mid-call media feature tag as described in annex C; or 

B. there is no ongoing active full-duplex speech session and the Contact header field received during the 
establishment of the ongoing inactive full-duplex speech session which became inactive most recently 
includes the g.3gpp. mid-call media feature tag as described in annex C. 

When the SC UE applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.2.1, and before sending a message to set up a call over the CS domain, the SC UE shall: 

1. if there are two or more ongoing active full-duplex speech sessions: 

A. initiate the release of all the ongoing full-duplex speech sessions except two that were most recently made 
active; 

B. initiate the session modification of the ongoing full-duplex speech session that was made active less recently 
and offer the full-duplex speech component with "sendonly" or "inactive" directionality; and 
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C. transfer two remaining ongoing full-duplex speech sessions; 

NOTE 1 : When active and inactive ongoing full-duplex speech sessions exist, one CC SETUP message transfers 
both sessions. 

2. if there are one ongoing active full-duplex speech session and one or more ongoing inactive full-duplex speech 
session, 

A. initiate the release of all the ongoing inactive full-duplex speech sessions except the one which became 
inactive most recently; and 

B. transfer two remaining ongoing full-duplex speech sessions; 

3. if there is one ongoing active full-duplex speech session and no ongoing inactive full-duplex speech session, 
transfer the ongoing full-duplex speech session; and 

4. if there is no ongoing active full-duplex speech session and there is one or more ongoing inactive full-duplex 
speech sessions: 

A. initiate the release of all the ongoing inactive full-duplex speech sessions except the one which became 
inactive most recently; and 

C. transfer the ongoing full-duplex speech session. 

NOTE 2: The ongoing inactive full-duplex speech sessions is transferred to a held CS call. 

The SC UE shall associate the additional transferred session with CS call with transaction identifier calculated as in the 
table 9.2.1A-1 and TI flag value as in mobile originated call. 

Table 9.2.1 A- 1 : held session transaction identifier calculation formula 



<transaction identifier of the additional transferred session> = (1 + <transaction identifier 
of the CS call established by the SETUP message>) modulo 7 



The SC UE shall consider session with speech: 

which has "sendonly" or "inactive" directionality as inactive; and 
- which has "recvonly" or "sendrecv" directionality as active; 
in this subclause and in the referenced subclauses. 

9.2.1 B SC UE procedures for PS to CS access transfer with MSC server 
assisted mid-call feature for speech and video session 

When PS to CS access transfer occurs, with a speech and video session and another speech session using PS media in 
the SC UE, the SC UE applies the MSC Server assisted mid-call feature according to the procedures described in 
subclause 9.2. 1A with the following additions: 

if the SC UE supports SCUDIF feature, and the speech and video session is active and speech session is inactive 
the SC UE shall transfer the active speech and video session as specified in subclause 9.2.1, and indicate the 
support of SCUDIF in the CC SETUP message as specified in 3GPP TS 24.008 [8], with multimedia bearer 
capability preferred for the current active session; and 

if the SC UE supports SCUDIF feature, and the speech and video session is inactive and speech session is active, 
the SC UE shall transfer the speech session as specified in subclause 9.2.1, and indicate the support of SCUDIF 
in the CC SETUP message as specified in 3GPP TS 24.008 [8], with speech bearer capability preferred for the 
current active session. 

NOTE: After successful transfer of the speech and video session and another speech session from PS to CS, the 

UE can switch between the two sessions by holding/releasing the active session and resuming the inactive 
session as specified in 3GPP TS 24.008 [8], with the addition that the UE can initiate the in-call 
modification or Redial procedures as specified in 3GPP TS 24.008 [8] to change the shared CS bearer of 
the two sessions from speech to multimedia, or vice versa. 
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9.2.2 SC UE procedures for CS to PS access transfer 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CS call setup procedure is complete, e.g. a CC CONNECT message has been sent or 
received as described in 3GPP TS 24.008 [8] or a call for which the SIP 2xx response for the initial SIP INVITE request 
to establish this session has been sent or received. 

If not already registered in the IM CN subsystem, the SC UE shall follow the procedures specified in subclause 6.2 to 
perform registration over the Target Access Leg before performing CS to PS access transfer. 

If SC using ICS is enabled then if the original sessions are established using ICS capabilities as defined in 
3GPP TS 24.292 [4], then for each session to be transferred and starting with the active session, the SC UE shall send a 
SIP INVITE request to the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. The SC 
UE shall populate the SIP INVITE request as specified for PS-PS access transfer with full media transfer in 
subclause 10.2.1. 

If the original sessions are not established using ICS capabilities and the SC UE does not support the MSC Server 
assisted mid-call feature as described in subclause 9.2.3, then access transfer is only possible when the SC UE is active 
in a single full-duplex speech session. If multiple full-duplex speech sessions exist, the SC UE shall first initiate the 
release of all the ongoing sessions that are currently not active and then the SC UE shall transfer the remaining ongoing 
active full-duplex speech session. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send a SIP INVITE request to the SCC AS 
in accordance with the UE procedures specified in 3GPP TS 24.229 [2] . The SC UE shall populate the SIP INVITE 
request as follows: 

1) the Request-URI set to the static STI; and 

2) include in the Contact header field a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2], if a 
GRUU was received at registration. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the CS domain. 

When the SC UE receives a CS call release message, e.g. CC DISCONNECT message as specified in 

3GPP TS 24.008 [8], from the network, the SC UE shall comply with network initiated call release procedures to 

release the CS bearer. 

9.2.3 SC UE procedures for CS to PS access transfer with MSC server 
assisted mid-call feature 

When the SC UE supports the MSC Server assisted mid-call feature, the SC UE shall populate the SIP INVITE request 
for transferring the session not using ICS capabilities as follows in addition to the procedures described in 
subclause 9.2.2: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

2. the Accept header field containing the MIME type as specified in annex D.1.3; and 

3. include in the Contact header field the g.3gpp. mid-call media feature tag as described in annex C. 

NOTE 1 : If the original sessions are not established using ICS capabilities as defined in 3GPP TS 24.292 [4] and 
the SCC AS and the SC UE support the MSC Server assisted mid-call feature, up to one active and up to 
one inactive full-duplex speech session can be transferred. 

Upon receiving a SIP REFER request within the SIP session established by the SIP INVITE request for transferring the 
session not using ICS capabilities: 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Target-Dialog URI header field in the URI of the Refer-To header field; 
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4. where the g.3gpp. mid-call media feature tag as specified in annex C was included in the Contact header field of 
the SIP 2xx response to the SIP INVITE request; and 

5. containing a MIME body of MIME type specified in the annex D. 1 .3; 

and if the SC UE supports the MSC Server assisted mid-call feature, then the SC UE shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for an additional inactive session in accordance with the procedures specified in 
3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request as follows: 

A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field: 

a. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

b. the g.3gpp. mid-call media feature tag as described in annex C; and 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 

d. media directionality as in the "body" URI header field in the URI in the Refer-To header field of the 
received SIP REFER request. 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 

The SC UE shall consider session with speech: 

- which has "sendonly" or "inactive" directionality as inactive; and 

- which has "recvonly" or "sendrecv" directionality as active; 
in this subclause and in the referenced subclauses. 

9.3 SCC AS 

9.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to STI". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI. In the procedures 
below, such requests are known as "SIP INVITE requests due to static STI". 
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- SIP INVITE requests routed to the SCC AS containing either a static STN, a STN-SR or an IMRN (as 

described in 3GPP TS 24.292 [4]) in the Request-URL In the procedures below, such requests are known as 
"SIP INVITE requests due to static STN". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

9.3.2 SCC AS procedures for PS to CS access transfer 

This subclause does not apply to recepetion of a SIP INVITE request due to STI with CS media and other kind of media 
or without CS media. 

When the SCC AS receives a SIP INVITE request due to STI with CS media only on the Target Access Leg, the SCC 
AS shall follow the procedures specified in subclause 10.3.2 with the following exceptions: 

As the SIP INVITE request includes an active speech media component using CS bearer, then the SCC AS shall 
follow the procedures for SCC AS for service control over Gm in 3GPP TS 24.292 [4] to send the PSI DN to the 
SC UE and wait for the SC UE to set up CS bearer before sending re-INVITE to the remote end. 

The SCC AS shall correlate the STI with the allocated PSI DN in order to identify the remote leg to be updated. 

When the SCC AS receives SIP INVITE request due to static STN, the SCC AS shall associate the SIP INVITE request 
with an ongoing dialog supporting a session based on information associated with the received IMRN (as described in 
3GPP TS 24.292 [4]) or based on information from the SIP History-Info header field and P- Asserted header field and 
send a SIP re-INVITE request towards the remote UE using the existing established dialog. By an ongoing dialog 
supporting a session, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent 
or received. Multiple dialogs supporting a session associated with the same SC UE may have been anchored when the 
SCC AS receives a SIP INVITE request due to static STN. This can occur in the event that the UE does not succeed in 
releasing all dialogs supporting a session with inactive audio media or if the UE applies the MSC Server assisted mid- 
call feature. The identification of the associated dialog is subject to the following conditions: 

1 . if only one dialog supporting a session with active audio media exists for the user identified in the P-Asserted- 
Identity header field and a SIP 2xx response has been sent, then continue the session transfer with the dialog 
supporting a session with active audio media; 

2. if no dialogs supporting a session with active audio media exist for the user identified in the P-Asserted-Identity 
header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid- 
call feature as specified in subclause 9.3.2A, then send a SIP 480 (Temporarily Unavailable) response to reject 
the SIP INVITE request relating to the session transfer; 

3. if more than one dialog supporting a session with active audio media exists for the user identified in the P- 
Asserted-Identity header field for which SIP 2xx responses have been sent, then the SCC AS shall perform 
session transfer procedures for the dialog that originates from the same device that initiated the received INVITE 
request due to static STN. If more than one such dialogs exists from the same device, the SCC AS shall proceed 
with the next step in this list; and 

NOTE 1 : Whether the dialog originates from the same UE as the received SIP INVITE request is determined based 
on local information and information related to the correlation MSISDN or the Instance-ID of the 
originating user as determined via registration procedures as defined in subclause 6.3. 

4. if more than one dialog supporting a session exists for the user identified in the P-Asserted-Identity header field 
and exactly one dialog supporting a session with active audio media exists and a SIP 2xx response has been sent 
for that dialog, then: 

if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, then 
the SCC AS may release the dialogs supporting a session with inactive audio media and continue the session 
transfer procedures with the dialog supporting a session with active audio media; or 

- if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 
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5. if more than one dialog supporting a session with active audio media exist for the user identified in the P- 
Asserted-Identity header field and a SIP 2xx response has been sent for that dialog, then: 

- if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, the 
SCC AS may release all dialogs supporting a session with audio media of the user identified in the P- 
Asserted-Identity header field for which a SIP 2xx response has been sent except the one with the active 
audio media that was most recently made active and continue the session transfer procedures; or 

- if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to static STN, 
by following the rules of 3GPP TS 24.229 [2] . 

Upon receiving the SIP ACK request from the IM CN subsystem, then: 

- if the source access leg contains only one audio media components the SCC AS shall initiate release of the 
source access leg by sending a SIP BYE request toward the S-CSCF for sending to the served SC UE; or 

If the Source Access Leg contains media components other than audio media component, the SCC AS should 
send a SIP re-INVITE request to update the source access leg. 

9.3.2A SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature 

The SCC AS shall apply the MSC Server assisted mid-call feature if: 

1. the Contact header field of the SIP INVITE request due to static STN includes the g.3gpp. mid-call media feature 
tag as specified in annex C; 

2. one of the following is true: 

A. at least one dialog supporting a session with active audio media exists for the user identified in the P- 
Asserted-Identity header field and the Contact header field provided by the SC UE at the establishment of the 
dialog supporting a session with active audio media which has been most recently made active includes the 
g.3gpp. mid-call media feature tag as described in annex C; or 

B. no dialog supporting a session with active audio media exists for the user identified in the P-Asserted-Identity 
header field, one or more dialogs supporting a session with inactive audio media exists for the user and the 
Contact header field provided by the SC UE at the establishment of the dialog supporting a session with 
inactive audio media which became inactive most recently includes the g.3gpp. mid-call media feature tag as 
described in annex C; 

3. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

4. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, and before determining that the SCC AS is not able to identify one dialog for session transfer, the SCC 
AS may: 

1 . if more than one dialog supporting a session exists for the user identified in the P-Asserted-Identity header field, 
and exactly one dialog supporting a session with active audio media exists, and a SIP 2xx response has been sent 
for that dialog and there is at least one remaining dialog supporting a session with inactive audio media, release 
all dialogs supporting a session with inactive audio media except the one with the audio media which became 
inactive most recently and continue the session transfer procedures with the dialog supporting a session with 
active audio media; 
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2. if more than one dialog supporting a session with active audio media exists for the user identified in the P- 
Asserted-Identity header field and a SIP 2xx response has been sent for these dialogs, release all dialogs 
supporting a session with audio media except two with the audio media which became active most recently and 
continue the session transfer procedures with the dialog supporting a session with the audio media which became 
active most recently; and 

3. if no dialog supporting a session with active audio media exists for the user identified in the P-Asserted-Identity 
header field, one or more dialogs supporting a session with inactive audio media exists for the user and a SIP 2xx 
response has been sent for these dialogs then the SCC AS may release all dialogs supporting a session with audio 
media except the one with the audio media which became inactive most recently and continue the session 
transfer procedures with the dialog supporting a session with inactive audio media. 

Editor's note: transport of the session state information in conferencing sessions is FFS 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact 
header field of the SIP 2xx response to the SIP INVITE request due to static STN. 

When the SCC AS applies the MSC Server assisted mid-call feature and a dialog supporting a session with inactive 
audio media was associated with the SIP INVITE request due to static STN, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall set the directionality of the audio media in the SDP offer as used in the session with 
remote UE. 

If the SCC AS applies the MSC Server assisted mid-call feature, two SIP dialogs supporting a session with an audio 
media exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for those 
dialogs then the SCC AS shall send a SIP REFER request towards the MSC Server in accordance with the procedures 
specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP 
INVITE request due to static STN. The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the information related to the session with an audio media other than the 
session associated with the SIP INVITE request due to static STN, i.e. set to the URI provided by SCC AS in the 
Contact header field to the SC UE during the session establishment and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the SC UE; 

B. the Require URI header field populated with the option tag value "tdialog"; 

C. the To URI header field populated as specified in IETF RFC 3261 [19], containing the P-Asserted-Identity 
provided by the remote UE during the session establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user identity 
of the SC UE provided during the session establishment; 

E. the Content-Type header field with "application/sdp"; and 

F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 
session with the remote UE and: 

a. if directionality used by SC UE is "sendrecv" or "sendonly", with the "sendonly" directionality; and 

b. if directionality used by SC UE is "recvonly" or "inactive", with the "inactive" directionality. 

4. the Content-Type header field with the value set to MIME type as specified in the annex D.1.3; and 

5. a XML body compliant to the XML schema specified in the annex D. 1 .2. 
The SCC AS shall consider dialog supporting a session with audio media: 

which has "sendonly" or "inactive" directionality at the SC UE as inactive; and 
which has "recvonly" or "sendrecv" directionality at the SC UE as active; 
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in this subclause and in the referenced subclauses. 

9.3.3 SCC AS procedures for CS to PS access transfer 

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only. 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to static STI, the SCC AS shall associate the SIP INVITE 
request with an ongoing dialog supporting a session. By an ongoing dialog supporting a session, it is meant a dialog for 
which a SIP 2xx response to the initial SIP INVITE request has been sent or received. Multiple dialogs supporting a 
session associated with the same SC UE may have been anchored when the SCC AS receives a SIP INVITE request due 
to static STI. This can occur in the event that the UE does not succeed in releasing all dialogs supporting a session with 
inactive audio media or if the UE supports the MSC Server assisted mid-call feature, in which case the identification of 
the associated dialog is subject to the following conditions: 

1 . if only one dialog supporting a session with active audio media exists for the user identified in the P-Asserted- 
Identity header field and a 2xx response has been sent, then continue the session transfer procedures; 

2. if no dialogs supporting a session with active audio media exist for the user identified in the P-Asserted-Identity 
header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid- 
call feature as specified in subclause 9.3.4, then send a SIP 480 (Temporarily Unavailable) response to reject the 
SIP INVITE request relating to the session transfer; 

3. if more than one dialog supporting a session exists for the user identified in the P- Asserted -Identity header field 
and exactly one dialog supporting a session with active audio media and a SIP 2xx response has been sent for 
that dialog, then: 

A. if the remaining dialogs support a session with inactive audio media and the SCC AS does not apply the 
MSC Server assisted mid-call feature as specified in subclause 9.3.4, then the SCC AS may release the 
dialogs supporting a session with inactive audio media and continue the session transfer procedures with the 
dialog supporting a session with active audio media; and 

4. if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS sends a SIP re-INVITE request towards the remote UE using 
the existing established dialog. The SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to the static STI, 
by following the rules of 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request originated from the UE, the SCC AS shall initiate release of the source access leg 
by sending a SIP BYE request over the source access leg. 

If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request originated 
from the UE being received from the IM CN subsystem for the source access leg, the SCC AS decides (for any reason) 
to reject the session transfer request back to the UE (e.g. by sending a SIP 4xx response), the SCC AS shall release the 
target access leg and maintain the source access leg. 

9.3.4 SCC AS procedures for CS to PS access transfer with MSC server 
assisted mid-call feature 

The SCC AS shall apply the MSC Server assisted mid-call feature if: 

1. the Contact header field of the SIP INVITE request due to static STI includes the g.3gpp. mid-call media feature 
tag as specified in annex C; 

2. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 
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3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.3, and before determining that the SCC AS is not able to identify one dialog for session transfer, SCC AS 
may: 

1 . if more than one dialog exists for the user identified in the P-Asserted-Identity header field, and exactly one 
dialog supporting a session with active audio media exists, and a SIP 2xx response has been sent for that dialog 
and there is at least one remaining dialog supporting a session with inactive audio media, release all dialogs 
supporting a session with inactive audio media except the one with the audio media which became inactive most 
recently and continue the session transfer procedures with the dialog supporting a session with active audio 
media ; and 

2. if no dialog supporting a session with active audio media exists for the user identified in the P-Asserted-Identity 
header field, one or more dialogs supporting a session with inactive audio media exists for the user and a SIP 2xx 
response has been sent for these dialogs then the SCC AS may release all dialogs supporting a session with audio 
media except the one with the audio media which became inactive most recently and continue the session 
transfer procedures with the dialog supporting a session with inactive audio media. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact 
header field of the SIP 2xx response to the SIP INVITE request due to static STL 

When the SCC AS applies the MSC Server assisted mid-call feature and a dialog supporting a session with inactive 
audio media was associated with the SIP INVITE request due to static STI, in addition to the procedures described in 
subclause 9.3.3, the SCC AS shall set the directionality of the audio media in the SDP offer as used in the session with 
remote UE. 

If the SCC AS applies the MSC Server assisted mid-call feature, two SIP dialogs supporting a session with an audio 
media exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for those 
dialogs then the SCC AS shall send a SIP REFER request towards the SC UE in accordance with the procedures 
specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP 
INVITE request due to static STI. The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the information related to the session with an audio media other than the 
session associated with the SIP INVITE request due to static STI, i.e. set to the URI provided by SCC AS in the 
Contact header field to the SC UE during the session establishment and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the MSC Server; 

B. the Require URI header field populated with the option tag value "tdialog"; 

C. the To URI header field populated as specified in IETF RFC 3261 [8], containing the P-Asserted-Identity 
provided by the remote UE during the session establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [8], containing the public user identity 
of the SC UE provided during the session establishment; 

E. the Content-Type header field with "application/sdp"; and 

F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 
session with the remote UE and with directionality as used by the MSC Server. 

4. the Content-Type header field with the value set to MIME type specified in the annex D.1.3; and 

5. a 3GPP IM CN subsystem XML body compliant to the XML schema specified in the annex D.1.2. 
The SCC AS shall consider dialog supporting a session with audio media: 

- which has "sendonly" or "inactive" directionality at the MSC Server as inactive; and 
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which has "recvonly" or "sendrecv" directionality at the MSC Server as active; 
in this subclause and in the referenced subclauses. 

9.4 MSC Server enhanced for ICS 

9.4.1 MSC Server enhanced for ICS procedures for PS to CS session 
continuity with MSC server assisted mid-call feature 

Editor's note: it is FFS how to ensure that the UE and the MSC Server would use the same transaction identifers for 
the conferencing sessions 

In addition to the procedures specified in 3GPP TS 29.292 [18], the MSC Server enhanced for ICS supporting the MSC 
Server assisted mid-call feature shall populate the SIP INVITE request as follows: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

2. the Accept header field containing the MIME type as specified in annex D.1.3; and 

3. include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C. 

NOTE 1: Since the MSC Server is not able to distinguish the dual radio access transfer from the regular session set 
up, the information elements above are added to every SIP INVITE request sent by the MSC Server. 

Upon receiving a SIP REFER request 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field; 

4. sent inside an existing SIP dialog: 

A. which was originated by the MSC Server; and 

B. where the g.3gpp.mid-call media feature tag as specified in annex C was included in the Contact header field 
of the SIP 2xx response to the SIP INVITE request; and 

5. containing a MIME body of MIME type specified in the annex D.1.3; 

and if the MSC Server enhanced for ICS supports the MSC Server assisted mid-call feature, then the MSC Server 
enhanced for ICS shall: 

1. handle the SIP REFER request as specified in 3GPP TS 29.292 [18], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for transfer of an additional inactive session not using ICS capabilities in accordance 
with the procedures specified in 3GPP TS 29.292 [18] and IETF RFC 3515 [13]. Additionally, the MSC Server 
enhanced for ICS shall populate the SIP INVITE request as follows: 

A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C; and 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 
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c. port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 

d. media directionality, as in the "body" URI header field in the URI in the Refer-To header field of the 
received SIP REFER request 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 

If two sessions are transferred, the MSC Server enhanced for ICS shall associate the SIP INVITE request for an 
additional inactive session with CS call with transaction identifier calculated as in the table 9.2.1A-1 and TI flag value 
as in mobile originated call. 

9.4.1 A MSC Server enhanced for ICS procedures for PS to CS session 

continuity with MSC server assisted mid-call feature for speech and 
video session 

If the MSC Server enhanced for ICS supports the MSC Server assisted mid-call feature, upon receiving the session state 
information which indicates an inactive speech and video session, the MSC Server enhanced for ICS shall send a SIP 
INVITE request for the additional inactive speech and video session as described in subclause 9.4.1 A. 

NOTE 1: If due to some reason (i.e. the current RAN type not supporting video, lack of resource, etc.) the video 

media can not be supported in CS network for the speech and video session, then the MSC Server can set 
the port to zero in the "m=" line for the video media in the SDP offer of the SIP INVITE request for the 
additional inactive session, so as to inform the SCC AS that the video media is deleted and only the audio 
media of the speech and video session is transferred to CS. 

NOTE 2: After successful transfer of a speech and video session and a speech session from PS to CS, if messages 
are received from the UE to switch between the two sessions (i.e. HOLD/Release message to hold/release 
the active session and Retrieve message to retrieve the inactive session), the MSC Server enhanced for 
ICS can perform the procedures as specified in 3GPP TS 29.292 [18], with the addition that the MSC 
Server enhanced for ICS can complete the in-call modification or Redial procedures as specified in 
3GPP TS 24.008 [8] to change the shared CS bearer of the two sessions from speech to multimedia, or 
vice versa, before sending a SIP UPDATE or SIP re-INVITE message to the SCC AS to resume the 
inactive session. 



1 Roles for PS-PS access transfer 
10.1 Introduction 

This clause specifies the procedures for PS-PS access transfer for both full media transfer case and partial media 
transfer case. Procedures are specified for the SC UE and the SCC AS. 



10.2 SCUE 
10.2.0 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been 
sent or received. 

The SC UE shall follow the procedures specified in subclause 6.1 to perform registration in the IM CN subsystem on 
the newly selected access network before performing PS-PS access transfer. 
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1 0.2.1 Full session transfer 

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request over the Target Access Leg 
in accordance with UE procedures specified in 3 GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request 
as follows: 

1 . the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

2. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3 GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B. the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3. select one of the following options: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the session to be transferred; and 

b. the Require header field populated with the option tag value "replaces"; 

B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session to be transferred; and 

b. the Require header field populated with the option tag value "tdialog"; and 

4. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same 
number of media lines in the same order, where each media line corresponds to one of the media components in 
the original session, unless media components need to be added, and such that each media line indicates the 
same media type as its corresponding media component in the original session and contains at least one codec 
that was negotiated during the original session. 

A. - If the SC UE determines to remove a media component during the transfer, then the SC UE shall set the 

media line for this media component to a port number with value zero; and 

B. - If the SC UE determines to add new media component(s) during the transfer, then the SC UE shall include 

one additional media line with the desired media type and codecs for each new media component at the end 
of the SDP. 

NOTE: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 
control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabilities (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, if the dialog over the Source Access Leg is still active, the SC UE shall send a SIP BYE request to the SCC AS 
over the Source Access Leg to terminate the original session. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS access transfer has not completed successfully and the call will continue in the Source Access Leg. 
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1 0.2. 1 A Additional procedures for full session transfer when MSC server 
assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.1, if the SC UE supports the MSC Server assisted mid-call 
feature, the SC UE shall include in the Contact header field of the SIP INVITE request the g.3gpp. mid-call media 
feature tag as described in annex C. 

1 0.2.2 Partial session transfer 

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request over the Target Access Leg 
in accordance with UE procedures specified in 3 GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request 
as follows: 

1 . the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

2. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B. the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3. the Require header field with the option tag 'tdialog' included; 

4. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 
the session to be transferred; and 

5. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same 
number of media lines in the same order, where each media line corresponds to one of the media components in 
the original session, unless media components need to be added during the session transfer, and such that each 
media line indicates the same media type as its corresponding media component in the original session and 
contains at least one codec that was negotiated during the original session. 

A. If the SC UE determines to keep the media component on the Source Access Leg, then the SCUE shall set 
the media line for this media component to a port number with value zero; and 

B. If the SC UE determines to add new media component(s) during the transfer, then the SC UE shall include 
one additional media line with the desired media type and codecs for each new media component at the end 
of the SDP. 

NOTE: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 
control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabilities (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, the SC UE shall send a SIP re-INVITE request to the SCC AS over the Source Access Leg to update the 
original session. The SC UE shall populate the SIP re-INVITE request as follows: 

1 . the SDP payload set for all the media component(s) within the original session, in accordance with the UE SDP 
origination procedures specified in 3GPP TS 24.229 [2]. The SC UE shall set the port number for a media 
component to zero if that media component has been transferred to the Target Access Leg or has to be removed. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS access transfer has not completed successfully and the call will continue in the Source Access Leg. 
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1 0.2.3 Additional procedures for partial session transfer when MSC server 
assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.2, if the SC UE supports the MSC Server assisted mid-call 
feature, the SC UE shall include in the Contact header field of the SIP INVITE request the g.3gpp. mid-call media 
feature tag as described in annex C. 

10.3 SCC AS 

1 0.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field. In the procedures below such requests are known as "SIP INVITE 
requests due to STI". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 0.3.2 PS to PS access transfer procedures at the SCC AS 

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only. 

When the SCC AS receives a SIP INVITE request on the Target Access Leg due to STI, the SCC AS shall: 

associate the SIP INVITE received on the Target Access Leg with an ongoing SIP dialog i.e. identify the 
Source Access Leg. The Source Access Leg is identified by matching the dialog ID present in the Replaces (see 
IETF RFC 3891 [10]) or Target Dialog header field (see IETF RFC 4538 [1 1]) of the SIP INVITE with an 
ongoing dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP 
INVITE request has been sent or received; 

if the SCC AS is unable to associate the SIP INVITE with a unique ongoing dialog, send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not 
processes the remaining steps; 

if the SIP INVITE request contains a Replaces header field: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [8]; and 

b) send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to STI 
received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. 

- otherwise, if the SIP INVITE request contains a Target Dialog header field: 

a) if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media lines is not the same as in the original session, 
send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the 
remaining steps; 
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b) otherwise, send a SIP re-INVITE request towards the remote UE using the existing established dialog. The 
SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) include a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following 
media information: 

- the media characteristics as received in the SIP INVITE request due to STI received on the Target 
Access Leg for media streams whose port is not set to zero; and 

for the media streams in the SIP INVITE request due to STI whose port is set to zero, include the 
corresponding media characteristics of those streams from the Source Access Leg, 

c) for a full media transfer, send a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]; 
otherwise, for a partial media transfer, after receiving the SIP ACK request from the SC UE on the Target 
Access Leg, upon receiving an update (e.g. SIP re-INVITE) from the SC UE on the Source Access Leg, 
process the update request in accordance with 3GPP TS 24.229 [2]. 

If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request being 
received on the Target Access Leg, the SCC AS decides (for any reason) to reject the access transfer request (e.g. by 
sending a 4xx response), the SCC AS shall release the Target Access Leg, retain the Source Access Leg, and update the 
remote leg to match the Source Access Leg. 

1 0.3.3 Additional SCC AS procedures for PS to PS access transfer when 
MSC server assisted mid-call feature is supported 

If: 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; 

2. the g.3gpp. mid-call media feature tag as described in annex C is included in the Contact header field of the SIP 
INVITE request due to STI; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

then the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field 
of the SIP 2xx response to the SIP INVITE request due to STI in addition to the procedures described in 
subclause 10.3.2. 



1 1 Roles for PS-PS access transfer in conjunction with 
PS-CS access transfer 

11.1 Introduction 

This clause specifies the procedures for PS-PS access transfer in conjunction with PS-CS access transfer. Procedures are 
specified for the SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-PS access transfer 
with a remote end in conjunction with PS-CS access transfer with the same remote end is only possible when the UE is 
active in a single CS session with full-duplex speech with the remote end i.e. support of session transfer with more than 
one session containing full-duplex speech component is not provided. 
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11.2 SCUE 

11 .2.1 SC UE procedures for PS to PS+CS access transfer 

11.2.1.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been 
sent or received. 

1 1 .2.1 .2 SC UE procedures for PS to PS+CS access transfer using ICS 

This subclause applies for IMS sessions containing not only speech media component, otherwise subclause 9.2.1 
applies. 

If SC using ICS is enabled then if the SC UE is using Gm, then for each session to be transferred and starting with the 
session with active full-duplex speech component, the SC UE shall send a SIP INVITE request to the SCC AS as 
specified for call origination for ICS UE using Gm in 3GPP TS 24.292 [4]. The SC UE shall populate the SIP INVITE 
request as specified for PS-PS access transfer with full media transfer in subclause 10.2.1 with the following exceptions: 

- The SC UE shall indicate in the SIP INVITE request that the speech media is using CS bearer with its 
corresponding media description. 

- When sending the SIP INVITE request for the sessions with inactive full-duplex speech component and if 
precondition is used, the SC UE shall indicate that the related local preconditions for the speech component are 
met. 

- For the session with active full-duplex speech component, upon receiving the PSI DN from the SCC AS, the SC 
UE shall follow the procedures for call origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up the CS 
bearer. 

If service control over Gm for the CS bearer is retained on the source access leg, the SC UE shall: 

- send an SIP INVITE request as specified for partial session transfer in subclause 10.2.2. indicating transfer of 
non-speech media to the target access leg; and 

send a SIP re-INVITE request over the source access leg indicating that the speech media is to be transferred to a 
CS bearer as described in 3GPP TS 24.292 [4] subclause 8.2.2.2. If other media components are retained or 
added on the source access leg, then these are included in the SDP offer. 

For the session with active full-duplex speech component, upon receiving the SCC AS PSI DN from the SCC AS, the 
SC UE shall follow the procedures for call origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up the CS 
bearer. 

1 1 .2.1 .3 SC UE procedures for PS to PS+CS access transfer not using ICS 

If the SC UE is not using ICS capabilities, then access transfer is only possible when the UE is active in a single session 
with full-duplex speech media component. For the non-speech components to be transferred to the PS Target Access 
Leg, the SC UE shall send a SIP INVITE request to the SCC AS as specified for PS-PS access transfer with partial 
media transfer in subclause 10.2.1. For the speech component to be transferred to the CS Target Access leg, the SC UE 
shall send to the SCC AS a CC SETUP message as specified in 3GPP TS 24.008 [8]. When sending the CC SETUP 
message, the SC UE shall populate the CC SETUP message as follows: 

1) the called party BCD number information element set to the STN; 

2) Type Of Number set to "International" and Numbering Plan Indicator set to "E. 164" .in the Called Party BCD 
Number information element. 

Upon receiving the SIP 2xx response from the SCC AS for the PS Target Access Leg and sending SIP ACK request and 
upon receiving CS call setup confirmation message, e.g. CC CONNECT message, for the CS Target Access Leg, the 
SC UE shall send a SIP BYE request to terminate the Source Access Leg, following the procedures specified in 
3GPPTS 24.229 [2]. 
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If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access leg and receives 
CS call setup failure message for the CS Target Access Leg, then session transfer has not occurred and the call will 
continue in the original domains. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access Leg and 
receives CS call setup confirmation message for the CS Target Access Leg, then the session transfer is only successful 
for part of the media components. The SC UE shall update the Source Access leg by following the procedures specified 
for PS-PS access transfer with partial media transfer in subclause 10.2.2 to indicate that all media components other 
than the speech component are still maintained on the Source Access Leg. 

If the SC UE receives CS call setup failure message for the CS Target Access Leg but receives a SIP 2xx response for 
the PS Target Access Leg, then the session transfer is only successful for part of the media components. Upon sending 
SIP ACK request, the SC UE shall update the Source Access leg by following the procedures specified for PS-PS 
access transfer with partial media transfer in subclause 10.2.2 to indicate that the speech component is still maintained 
on the Source Access Leg. 

1 1 .2.2 SC UE procedures for PS+CS to PS access transfer 

11.2.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CC CONNECT message has been sent or received or a call for which the SIP 2xx 
response for the initial SIP INVITE request to establish this session has been sent or received. 

If not already registered over the PS Target Access Leg, the SC UE shall follow the procedures specified in 
subclause 6.2 to perform IM CN subsystem registration over the Target Access Leg before performing PS/CS to PS 
access transfer. 

1 1 .2.2.2 SC UE procedures for PS+CS to PS access transfer using ICS 

If SC using ICS is enabled then if the original sessions are established using ICS capabilities as defined in 
3GPP TS 24.292 [4], then for each session to be transferred and starting with the session with active full-duplex speech 
media component, the SC UE shall send a SIP INVITE request to the SCC AS in accordance with the UE procedures 
specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as specified for PS-PS access 
transfer with full media transfer in subclause 10.2.1. The SC UE shall indicate in the SIP INVITE request that the 
speech media component is using PS media. 

Upon receiving SIP BYE request for the Source Access Leg, the SC UE shall follow the ICS using Gm procedures 
specified in 3GPP TS 24.292 [4] to release the session. The SC UE also releases the associated CS bearer if no other 
sessions depend on the CS bearer. 

1 1 .2.2.3 SC UE procedures for PS+CS to PS access transfer not using ICS 

If the original sessions are not established using ICS capabilities, then access transfer is only possible when the SC UE 
has a single session with active full-duplex speech media component. The SC UE shall send a SIP INVITE request to 
the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. 

The SC UE shall populate the SIP INVITE request as follows: 

- the Request-URI set to static STI; 

the Require header field including "replaces" option tag; 

- the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier of the 
session to be transferred on the PS Source Access Leg; and 

- the SDP payload set for the media component(s) to be transferred, in accordance the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2], The SC UE shall create an SDP offer that contains media 
components in the following order: 

1) the same number of media lines, each corresponding to one of the media components in the session on the PS 
Source Access Leg; For each media line the SC UE shall indicate the same media type as its corresponding 
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media component in the original session and indicate at least one codec that was negotiated during the 
original session. If the SC UE determines to remove a media component during the transfer, then the SC UE 
shall set the media line for this media component to include a port number with value zero; 

2) one speech media component to be transferred, corresponding to the speech media component in the session 
on the CS Source Access Leg; and 

3) if the SC UE determines to add new media component(s) during the transfer, then one additional media line 
with the desired media type and codecs each new media component. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the original domains. 

1 1 .3 SCC AS 

1 1 .3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to STI". 

SIP INVITE requests routed to the SCC AS containing either a static STN or an IMRN in the Request-URL In 
the procedures below, such requests are known as "SIP INVITE requests due to static STN". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI and a STI in the 
Replaces or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to two STIs". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
subclauses 11.3.2 and 11.3.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 1 .3.2 SCC AS procedures for PS to PS+CS access transfer 

This subclause does not apply to recepetion of a SIP INVITE request due to STI with a CS media. 

When the SCC AS receives a SIP INVITE request due to STI with PS and CS media on the Target Access Leg, the 
SCC AS shall follow the PS-PS Access Transfer procedures specified in subclause 10.3.2. with the following 
exceptions: 

If the SIP INVITE request includes an active speech media component using CS bearer, then the SCC AS shall follow 
the procedures for SCC AS for service control over Gm in 3GPP TS 24.292 [4] to send the PSI DN to the SC UE and 
wait for the SC UE to set up CS bearer before sending re-INVITE to the remote UE. 

- The SCC AS shall correlate the STI with the allocated PSI DN in order to identify the remote leg to be updated. 

If service control over Gm is retained on the source access leg, and the SCC AS receives a re-INVITE request 
indicating CS bearer on an existing session, the SCC AS shall follow procedures as described in 
3GPP TS 24.292 [4] subclause 8.4.2 to send the PSI DN to the SC UE and wait for the SC UE to set up CS 
bearer before sending re-INVITE to the remote end. 

- The SCC AS shall include a new SDP offer in the re-INVITE request, following the rules specified in 
3GPP TS 24.229 [2], containing the following media information: 

the media characteristics as received in the SIP INVITE request due to STI with PS+CS media received on 
the Target Access Leg for media streams whose port is not set to zero; and 
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- the media characteristics as received in the SIP re-INVITE request for media streams whose port is not set to 
zero. 

When the SCC AS receives a SIP INVITE request due to static STN on the Target Access Leg, the SCC AS shall 
follow the PS-CS Access Transfer procedures specified in subclause 9.3.2. However, as the Source Access Leg contains 
media components other than speech component, the SCC AS does not initiate release for Source Access Leg. 



1 1 .3.3 SCC AS procedures for PS+CS to PS access transfer 

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only. 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS access transfer procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to two STIs on the Target Access Leg, the SCC AS shall: 
associate the SIP INVITE request received on the Target Access Leg with two ongoing sessions: 

a) an ongoing SIP dialog on the PS Source Access Leg: This is done by matching the dialog ID present in the 
Replaces header field (see IETF RFC 3891 [10]) or Target-Dialog header field (see IETF RFC 4538 [11]) of 
the SIP INVITE request with an ongoing dialog. By an ongoing SIP dialog, it is meant a dialog for which a 
SIP 2xx response to the initial SIP INVITE request has been sent or received; 

b) a different ongoing SIP dialog with active full-duplex speech component: 

if the SCC AS is unable to associate the SIP INVITE request with either one of the above two dialogs, send a 
SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and 
not process the remaining steps; and 

if the session transfer is possible: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the two sessions on the Source Access 
Legs with the SIP request received on the Target Access Leg, including terminating the two Source Access 
Legs by sending a SIP BYE request on each session towards the SC UE in accordance with 

3GPP TS 24.229 [2]; and 

b) send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to two 
STIs received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. 



1 2 Roles for PS-CS access transfer, Single Radio 
12.1 Introduction 

This clause specifies the procedures for PS-CS access transfer in Single Radio VCC. Procedures are specified for the 
SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-CS access transfer in SR-VCC is 
only possible when SC is enabled, the UE is active in a single session with full-duplex speech i.e. support of session 
transfer with more than one session containing full-duplex speech component is not provided. 
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12.2 SC UE procedures for PS to CS access transfer, SR-VCC 

12.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before SR-VCC access transfer is performed. By an 
ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this 
session has been sent or received. 

12.2.2 ICS-based 

If: 

- SC using ICS is enabled; 

the Gm reference point is retained upon PS handover procedure; 

- the SC UE is using ICS capabilities as defined in 3GPP TS 24.292 [4]; and 

- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 

the SC UE, in order to add Gm control for the newly established CS session, shall: 

send a SIP re-INVITE request for each speech session to be transferred, starting with the session with active full- 
duplex speech component that was most recently made active; and 

within the SDP offer indicate the media line for all active and held audio streams as an audio stream over circuit 
switched bearer in accordance with 3GPP TS 24.292 [4]. If the precondition mechanism is used, the SC UE shall 
indicate the related local preconditions as met. 

NOTE: Within SR-VCC the handover is performed on PS level. Due to this, the SIP dialog established over the 
source PS access network stays the same after SR-VCC procedures, e.g. the IP address of the UE, the 
Call-ID, the P-CSCF do not change. Therefore in this case a re-INVITE needs to be sent to add ICS- 
control for the CS bearer. 

12.2.3 Not based on ICS 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8]), if the SC UE is not using ICS capabilities 
and the SC UE does not apply the MSC Server assisted mid-call feature as specified in subclause 12.2.3A, the SC UE 
shall replace the most recently active PS audio session with the newly established CS voice call. 

NOTE: In the case when ICS is not supported or used and the SC UE does not apply the MSC Server assisted 
mid-call feature, only the most recently active audio call is transferred from PS to CS audio. 

If: 

- the Gm reference point is retained upon PS handover; 
the SC UE is not using ICS capabilities; and 

- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
the SC UE shall: 

- send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1; and 

- indicate in the SDP offer the full-duplex speech media as removed. 

12.2.3A Not based on ICS with MSC Server assisted mid-call feature 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8]), if: 
1. the SC UE is not using ICS capabilities; 
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2. the SC UE supports the MSC Server assisted mid-call feature; and 

3. one of the following is true: 

A. there is at least one active PS audio session and the Contact header field received by the SC UE at the 
establishment of the active PS audio session, which has been most recently made active, includes the 
g.3gpp. mid-call media feature tag as described in annex C; or 

B. there is no active PS audio session and the Contact header field received by the SC UE at the establishment 
of the inactive PS audio session which became inactive most recently includes the g.3gpp. mid-call media 
feature tag as described in annex C. 

then the SC UE shall apply the MSC Server assisted mid-call feature as follows: 

1 . if two or more active PS audio sessions exist, the SC UE shall replace the PS audio components of the two most 
recently active PS audio sessions with the newly established active and held CS voice calls; 

2. if one active PS audio session exists and one or more inactive PS audio sessions exist, the SC UE shall replace 
the PS audio components of the active PS audio session and of the most recently inactive PS audio session with 
the newly established active and held CS voice calls; 

3. if one active PS audio session exists and no inactive PS audio sessions exist, the SC UE shall replace the PS 
audio component of the active PS audio session with the newly established active CS voice call; and 

4. if no active PS audio session exists and one or more inactive PS audio session exists, the SC UE shall replace the 
PS audio component of the inactive PS audio session which became inactive most recently with the newly 
established held CS voice call. 

Editor" s Note: It is FFS how to ensure that the UE and MSC Server would use the same transaction identifiers for 
the conferencing sessions. 

For each session, the SC UE shall proceed as specified in subclause 12.2.3. 

If two sessions are transferred, the SC UE shall associate the additional transferred session with CS call with transaction 
identifier 1 and TI flag value as in mobile terminated call. 

NOTE: The active session transaction identifier value is described in 3GPP TS 24.008 [8] 

The SC UE shall consider session with audio media: 

which has "sendonly" or "inactive" directionality as inactive; and 

which has "recvonly" or "sendrecv" directionality as active; 
in this subclause and in the referenced subclauses. 

If single inactive session is transferred, the SC UE shall associate the transferred session with CS call with transaction 
identifier and TI flag value as in mobile terminated call. 

12.2.4 Abnormal cases 

If the SC UE engaged in one or more ongoing IMS sessions receives a SM NOTIFICATION message containing an 
"SRVCC handover cancelled, IMS session re-establishment required" as described in 3 GPP TS 24.008 [8] or 
3GPP TS 24.301 [52] depending on the access in use, then the SC UE shall send a SIP relNVITE request containing an 
SDP offer, including the media characteristics as used in the existing dialog, by following the rules of 
3GPPTS 24.229 [2]. 

12.3 SCC AS 

1 2.3.1 SCC AS procedures for PS to CS access transfer, SR-VCC 

The SCC AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for SR- 
VCC: 
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SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request- 
URI. These SIP INVITE requests originate from the MSC server. In the procedures below, such requests are 
known as "SIP INVITE requests due to STN-SR". 

- SIP re-INVITE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate a CS bearer. In the procedures below, such requests are known as "SIP re-INVITE requests adding ICS 
control". 

- SIP re-INVITE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate the port set to "0". In the procedures below, such requests are known as "SIP re-INVITE requests for 
non-ICS control". 

When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg, and the SCC AS does not 
apply MSC Server assisted mid-call feature as described in subclause 12.3.2, the SCC AS shall follow the PS-CS access 
transfer procedures specified in subclause 9.3.2 for the session with active full-duplex speech component that was most 
recently made active. However, the SCC AS does not initiate release for Source Access Leg unless after some specific 
time defined by the operator policy. 

If the SCC AS has sent a SIP 480 (Temporarily Unavailable) response to reject a SIP INVITE request due to STN-SR 
on the Target Access Leg: 

1) if the speech media flow to be transferred was the only media flow in the SIP dialog, the SCC AS shall release 
the remote leg as specified in 3GPP TS 24.229 [2]; or 

2) if the SIP dialog contains other media flows than the active speech flow, the SCC AS shall modify the remote leg 
and remove the speech media flow, as specified in 3GPP TS 24.229 [2]. 

When the SCC AS receives a SIP re-INVITE request for adding ICS control, the SCC AS shall follow the procedures as 
described for ICS using Gm in subclause 13.3.2. 

NOTE: When using the ICS controlled CS bearer, only one audio call can be active at a time. Nevertheless, 

several calls can be held in parallel. If the user decides to switch to another (previously held) call, the ICS 
controlled CS bearer is re-used for this call. Therefore no specific procedures for handling of held calls in 
the case of ICS controlled CS bearer are needed. 

When the SCC AS receives a SIP re-INVITE for non-ICS control, the SCC AS shall follow the media removal 
procedures as specified in subclause 13.3.1. 

Unless the MSC Server assisted mid-call feature applies, as only the most recent active audio call is transferred from PS 
to CS audio, the SCC AS all drop all other previously existing audio session from this UE and indicate them 
accordingly in the SDP Offer sent within SIP re-INVITE requests towards the remote UE. 

1 2.3.2 SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature, SR-VCC 

if 

1. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to static STN, the 
SCC AS local policy requires delaying application of the MSC Server assisted mid-call feature for a time given 
by local policy and the inactive session transfer request has not been received within a time given by local policy 
after the reception of the SIP INVITE request due to static STN; 

2. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to static STN and 
the SCC AS local policy does not require delaying application of the MSC Server assisted mid-call feature for a 
time given by local policy; or 

3. the SC UE did not include the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to static STN; 

then SCC AS shall apply the MSC Server assisted mid-call feature as described in subclause 9.3.2A with the following 
differences: 
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1. the SCC AS shall release all the superfluous audio sessions; and 

2. the SCC AS does not initiate release for Source Access Leg of the associated SIP dialogs but remove speech 
media flow for these dialogs. 

Removing speech media flow for SIP dialogs, the SCC AS shall: 

- if the speech media flow was the only media flow in the SIP dialogs, release the source access leg as specified in 
3GPPTS 24.229 [2]; or 

- if the SIP dialogs contains other media flows than the speech flow, modify the source access leg and remove the 
speech media flow, as specified in 3GPP TS 24.229 [2]. 

The SCC AS shall consider session with speech: 

which has "sendonly" or "inactive" directionality at the SC UE as inactive; and 

- which has "recvonly" or "sendrecv" directionality at the SC UE as active; 
in this subclause and in the referenced subclauses. 



1 2.3.3 SCC AS procedures for SR-VCC, abnormal case 

When the SCC AS receives a SIP relNVITE request on the original source access leg after having initiated an access 
transfer that was triggered by a SIP INVITE request due to STN-SR and the SIP INVITE request due to STN-SR 
transaction is not yet completed then the SCC AS shall wait until this transaction has completed and then continue with 
the steps described below. 

When the SCC AS receives a SIP relNVITE request after having performed an access transfer that was triggered by a 
SIP INVITE request due to STN-SR, then the SCC AS shall: 

1) not release the original access leg once the expiration of that timer as described in subclause 12.3.1; and 

2) treat the SIP relNVITE request as per procedures for removing and adding media as described in 
subclause 13.3.1. 

NOTE: The SCC AS assigns an operator specific timer to delay the release of the Source Access Leg for SR- 
VCC access transfer. 

When the SCC AS receives a SIP response to the SIP relNVITE indicating success in removing all media components 
from the dialog that was created due to the SIP INVITE request due to STN-SR then the SCC AS shall send a SIP BYE 
request on this dialog, by following the rules of 3GPP TS 24.229 [2]. 



1 2.4 MSC server enhanced for ICS 

If the MSC server supports MSC Server assisted mid-call services feature, the MSC server shall be an MSC server 
enhanced for ICS as specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] with following modifications: 

1 . if two sessions are transferred, associate the SIP INVITE request for an additional inactive session with CS call 
with transaction identifier 1 and TI flag value as in mobile terminated call; 

NOTE: The active session transaction identifier value is described in 3GPP TS 24.008 [8] 

2. if single session is transferred and all the media in the SDP answer of the SIP 2xx response to the SIP INVITE 
request have directionality inactive, associate the SIP INVITE request for the session with CS call with 
transaction identifier and TI flag value as in mobile terminated call; and 

3. apply procedures as described in subclause 9.4. 
The MSC server shall consider session with audio media: 

- which has "sendonly" or "inactive" directionality as inactive; and 

- which has "recvonly" or "sendrecv" directionality as active; 
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in this subclause and in the referenced subclauses. 

12.5 EATF 

1 2.5.1 EATF procedures for PS to CS session continuity, E-SR-VCC 

The EATF needs to distinguish between the following SIP INVITE requests to provide specific functionality for E-SR- 
VCC: 

1. SIP INVITE request routed to the EATF due to E-STN-SR in the Request-URL In the procedures below, such 
requests are known as "SIP INVITE requests due to E-STN-SR". 

NOTE: The same E-STN-SR is used for all the emergency session access transfers within one PLMN. 

When the EATF receives a SIP INVITE request due to E-STN-SR on the Target Access Leg, the EATF shall: 

1. associate the SIP INVITE request due to E-STN-SR with a source access leg, i.e. an existing SIP session 
anchored at the EATF with the instance-id media feature tag provided by the SC UE in the Contact header field 
at session establishment equal to the instance-id media feature tag included in the Contact header field of the 
received SIP INVITE request. If no source access leg exists or if multiple source access legs exist, then the 
EATF shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to E-STN- 
SR; and 

2. originate session modification as described in 3GPP TS 24.229 [2] towards the remote UE with a new SDP offer 
with media characteristics as received in the SIP INVITE request due to E-STN-SR. 

Upon receiving the SIP ACK request from the Target Access Leg, the EATF shall release the source access leg as 
described in 3GPP TS 24.229 [2]. 

MSC server enhanced for SRVCC using SIP interface 

1 2.6.1 Session transfer from MSC server enhanced for SRVCC using SIP 
interface 

When an MSC server enhanced for SRVCC using SIP interface receives an indication for a session transfer as described 
in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP interface shall initiate a SIP INVITE 
request and shall: 

1) set the request URI to the STN-SR for the speech session to be transferred; and 

2) set the P-Asserted-Identity header field to the Correlation MSISDN. 

If the MSC server enhanced for SRVCC using SIP interface applies the MSC Server assisted mid-call features then in 
addition to the procedures in this subclause it shall support the procedures defined in subclause 12.4. 

1 2.6.2 Emergency session transfer from MSC server enhanced for SRVCC 
using SIP interface 

When an MSC server enhanced for SRVCC using SIP interface receives an indication for a session transfer for an 
emergency session as described in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP 
interface shall initiate a SIP INVITE request and shall: 

1) set the request URI to the E-STN-SR for the speech session to be transferred; 

2) include the instance-id feature tag as specified in IETF RFC 5626 [22] with a value based on the IMEI as defined 
in 3GPP TS 23.003 [12] in the Contact header field; and 

3) set the P-Asserted-Identity header field to the Correlation MSISDN if one is available. 
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1 3 Roles for media adding/deleting for access transfer 

13.1 Introduction 

This clause specifies the procedures for adding or deleting media to an existing multimedia session. Procedures are 
specified for the SC UE and the SCC AS. 

13.2 SCUE 

1 3.2.1 Adding or removing media through Gm 

If the SC UE wants to add or remove media components to a session that was previously established using Gm 
reference point, the SC UE shall follow the procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If the SC UE wants to transfer media components from the source access leg to an existing target access leg (i.e the 
access legs were previously established due to the partial session transfer) using Gm reference point, the SC UE shall: 

1. add the media components to the target access leg; and 

2. remove those media components from the source access leg, 

by using procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If SC using ICS is enabled then if the SC UE wants to add or remove CS media components to a session, it shall follow 
the procedures defined in 3GPP TS 24.292 [4]. 

If the SC UE receives a SIP re-INVITE request or a SIP UPDATE request from the remote UE to add or remove media 
components to a session that was previously established using Gm, the SC UE shall follow the procedures defined in 
3GPP TS 24.229 [2] for adding or removing PS media and shall follow the procedures defined in 3GPP TS 24.292 [4] 
for adding or removing CS media to the session. 

1 3.2.2 Adding Gm control to existing CS session 

The SC UE shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If there is more than one full -duplex speech session, the SC UE shall release all the ongoing sessions that are not 
currently active before attempting the procedures described in this section. 

If the SC UE wants to add Gm control to an existing CS session that was established without Gm, after registering with 
the IM CN subsystem, the SC UE shall send an initial SIP INVITE request over the PS access in accordance with 
3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows: 

- set the Request-URI to the static STI; and 

set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. The SC UE can optionally include additional PS media to the SDP in 
accordance to the procedures defined in 3GPP TS 24.229 [2]. 

Upon receiving a SIP 200 (OK) response, the SC UE shall treat the ongoing CS call as established using Gm and shall 
follow the "ICS UE using Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS call. 

If the SC UE receives a new SIP INVITE request containing an audio stream over a circuit-switched bearer in the SDP 
and the SCC AS PSI DN matches the B-party number of the ongoing CS call that was established without Gm, the SC 
UE shall: 

respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; and 

- treat the ongoing CS call as established using Gm and shall follow the "ICS UE using Gm" procedures defined in 
3GPP TS 24.292 [4] for controlling the CS call. 
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13.3 SCC AS 

1 3.3.1 Adding or removing media through Gm 

If the SCC AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE, in which already existing 
media components of the session are transferred from a source access leg to an already existing target access leg (i.e. 
the target access leg was already established due to partial session transfer), the SCC AS shall update the remote UE 
using the session transfer procedures defined in subclause 10.3.2. 

NOTE: The SC UE indicates that media is switched from the source access leg to the target access leg by using the 
procedures defined in 3GPP TS 24.229 [2] for adding / removing PS media, i.e. the related connection and port 
information of the transferred media component within the SDP is changed from the source access leg to the target 
access leg. 

If the SCC AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE or remote UE to 
add/remove new media components, to an existing access leg of the session established using Gm, the SCC AS shall 
follow the procedures defined in 3GPP TS 24.229 [2] for adding or removing PS media and shall follow the procedures 
defined in 3GPP TS 24.292 [4] for adding or removing CS media to the session. 

1 3.3.2 Adding Gm control to existing CS session 

If the SCC AS receives a SIP INVITE request containing the static STI in the Request-URI the SCC AS shall determine 
if this SIP INVITE request is for an ongoing call by determining if the received contents of SIP INVITE request's 
Contact header field is bound to an ongoing CS call session identifier. If the SC UE has an ongoing CS call, the SCC 
AS shall: 

- respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; 

- treat the ongoing CS call as established using Gm and shall follow the "SCC AS for service control over Gm" 
procedures defined in 3 GPP TS 24.292 [4] for controlling the CS call; and 

- if the SIP INVITE request contains additional PS media, the SCC AS shall send a SIP re-INVITE request 
towards the remote UE, including the newly added PS media, in accordance with the procedures defined in 
3GPPTS 24.229 [2]. 

The SCC AS shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If the SCC AS wants to add Gm control to an existing CS session that was established without Gm, the SCC AS 
shall send a new SIP INVITE request over the PS access in accordance with 3GPP TS 24.229 [2]. The SCC AS shall 
populate the SIP INVITE request as follows: 

set the Request-URI to the public user identity of the UE; and 

- set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. 

Upon receiving a SIP 200 (OK) response, the SCC AS shall treat the ongoing CS call as established using Gm and shall 
follow the "SCC AS for service control over Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS 
call. 



14 Roles for UE discovery for inter-UE transfer 
14.1 Introduction 

This clause specifies the target UE discovery procedures for UEs that are candidate UEs for inter UE transfer. The list 
of candidate UEs is a contact list such as name of the UE, which is represented in SIP through the use of SIP contact or 
the instance-id. The subscription of candidate UEs may be configured such that the private user identities associated 
with the UEs involved in inter UE transfer share the same set of implicitly registered public user identities. 
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14.2 SCUE 

The target UE discovery procedures include the registration status (active, inactive), and the UE capabilities (e.g. 
support of audio/video formats etc.). 

In order to determine a list of UEs sharing the same set of implicitly registered public user identities and their capability 
information, the SC UE subscribes to the reg-event package as described in 3GPP TS 24.229 [2] in subclause 5.1.1.3. 

NOTE 1 : In order to allow inter UE transfer to UEs belonging to the same subscription but belonging to a different 
set of implicitly registered public user identities, a user can have a static list of UEs that is manually 
administered by the user and stored locally in the user's device (e.g. phone book). Having a static list is an 
implementation in the UE and has no impact on the standards. 

NOTE 2: If the UE is not part of the same set of implicitly registered public user identities as the SC UE, or if the 
SC UE was unable to obtain the capability information of the UE through the use of reg-event package, 
the SC UE can send a SIP OPTIONS request to the UE to attempt to retrieve capability information. In 
order to avoid a lot of transactions, a SIP OPTIONS request is generated based on an action initiated by 
the user (e.g. after the user has finished adding a new UE in the static list, or the user explicitly asks for 
getting UE capability information). 



14.3 SCC AS 

The information of UEs that belong to the same subscription is required at the SCC AS for the purpose of authorizing 
that the requested inter UE transfer to the UE is allowed, i.e. to prevent the SC UE from performing Inter UE Transfer 
to a UE under a different subscription. 

The SCC AS obtains all the public user identities associated with the user's subscription from the Sh interface as 
specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7]. 

NOTE 1: Getting the public user identities over the Sh interface allows the SCC AS to receive information of UEs 
sharing the same set of implicitly registered public user identities and information of UEs within the same 
subscription that are not in the same set of implicitly registered public user identities. This is needed to 
authorize the static list of UEs that is manually administered by the user and stored locally in the user's 
device. 



The SCC AS can obtain the registration information (e.g. GRUU) by the following methods: 

1. using the 3rd-party SIP REGISTER request as described in 3GPP TS 24.229 [2] in subclause 5.4.1.7; or 

2. the SCC AS subscribes to the reg-event package as described in 3GPP TS 24.229 [2] in subclause 5.4.2.1.1. 

NOTE 2: The SCC AS needs to know the public user identity for the authorization of the SIP REFER request for 
inter UE transfer. To get the public user identity from the public GRUU, the SCC AS can simply remove 
the "gr" parameter from the public GRUU. Using the 3rd-party registration or subscribing to the reg-event 
package allows the SCC AS to find the temporary GRUU of the UE and to correlate the GRUU with the 
public user identities. After correlation, the SCC AS would make a list of GRUUs that are associated with 
the same subscription and/or with the same set of implicitly registered public user identities. 



1 5 Roles for inter-UE transfer without establishment of 
collaborative session 



15.1 Introduction 

This clause specifies the procedures for transferring all media of an existing session from one UE to another UE of the 
same subscriber. Procedures are specified for the transferor SC UE, the transferee SC UE and the SCC AS. 
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15.2 SCUE 

1 5.2.1 Transferor SC UE in services defining only originating session set 
up in UE 

In order to transfer all media of an existing session from this UE to another UE of the same subscriber, the SC UE shall 
send a SIP REFER request as specified in IETF RFC 3515 [13] and in accordance with UE procedures specified in 
3GPP TS 24.229 [2]. The SC UE shall populate the SIP REFER request as follows: 

1 . the Request-URI set to the URI of the UE where the session is to be transferred to; 

NOTE: The URI of the UE needs to be a GRUU if several UEs share the same public user identity. 

2. the Refer-To header field set to the Inter UE Transfer SCC AS URI and extended with the following URI header 
fields: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the Access Leg between this UE and the SCC AS; and 

b. the Require header field populated with the option tag value "replaces"; 

B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the Access Leg between this UE and the SCC AS; and 

b. the Require header field populated with the option tag value "tdialog"; and 

C. if the session is established using an IMS communication service that requires the use of an IMS 
communication service identifier: 

a. optionally the Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the IMS 
communication service identifier of the existing session; and 

b. the P-Preferred-Service header field set to the IMS communication service identifier of the existing 
session; and 

3. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3 GPP TS 24.229 [2]. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP REFER request or if the SC UE receives a SIP NOTIFY 
request containing a message/sipfrag body with SIP 4xx - 6xx response, then the inter UE transfer has not completed 
successfully. 

1 5.2.2 Transferee SC UE in services defining only originating session set 
up in UE 

When sending a SIP INVITE request upon SIP REFER request reception in accordance with UE procedures specified in 
3GPP TS 24.229 [2] and IETF RFC 3515 [13], the SC UE shall populate the SIP INVITE request with header fields 
which were included as URI header fields in the URI in the Refer-To header field of the received SIP REFER request. 

15.3 SCC AS 

1 5.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following SIP requests to provide specific functionality relating to inter 
UE transfer: 
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1 . SIP INVITE request routed to the SCC AS upon originating or terminating filter criteria containing the Inter UE 
Transfer SCC AS URI in the Request-URI and a STI belonging to the same subscriber in: 

A. the Target-Dialog header field; or 

B. in the Replaces header field 

with at least one offered media used in session by a UE other than the UE identified by the Contact header field 
value. In the procedures below, such request is known as "SIP INVITE request due to inter UE transfer". 

2. SIP REFER request routed to the SCC AS due to the originating filter criteria where: 

A. the GRUU in the Contact header field identifies a UE of the user identified in P-Asserted-Identity header 
field; 

B. the GRUU in the Contact header field identifies a UE of the same subscriber as the SIP URI in the Request- 
URI; and 

C. the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field 
belongs to a session of the UE identified by the GRUU in the Contact header field. 

In the procedures below, such request is known as "SIP REFER request due to inter UE transfer". 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 5.3.2 Inter UE transfer request authorization in services defining only 
originating session set up in UE 

Upon receiving a SIP REFER requests due to inter UE transfer, the SCC AS shall: 

1. reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps if: 

A. media of the session one leg of which is identified by the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field; 
are delivered to two or more UEs of the subscriber; or 

B. at least one media of the session identified by the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field 

is delivered to a UE other than the UE identified by the GRUU in the Contact header field; 

2. insert a Record-Route header field with SCC AS own address; and 

3. forward the SIP REFER request in any manner conformant with 3GPP TS 24.229 [2]. 

The SCC AS shall forward the SIP response to the SIP REFER request, the SIP NOTIFY request, and the SIP response 
to the NOTIFY request in any manner conformant with 3GPP TS 24.229 [2]. 

1 5.3.3 SCC AS procedures for inter UE transfer in services defining only 
originating session set up in UE 

Upon receiving a SIP INVITE request due to inter UE transfer, the SCC AS shall: 
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1. reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps if: 

A. the SCC AS is not aware of a subscription created by a SIP REFER request with the dialog identifiers: 

a. in the Replaces header field of the received SIP INVITE request and in the Replaces URI header field of 
the URI in the Refer-To header field of the SIP REFER request are equal; or 

b. in the Target-Dialog header field of the received SIP INVITE request and in the Target-Dialog URI 
header field of the URI in the Refer-To header field of the SIP REFER request are equal; 

2. associate the received SIP INVITE request with an ongoing SIP dialog by matching the dialog identifier in the 
Replaces header field or the Target-Dialog header field. By an ongoing SIP dialog, it is meant a dialog for which 
a SIP 2xx response to the initial SIP INVITE request has been sent or received; 

3. if dialog identifier is not included in either in the Replaces header field or in the Target-Dialog header field or if 
the included dialog identifier does not identify an existing ongoing dialog, send a SIP 480 (Temporarily 
Unavailable) response to reject the SIP INVITE request and not processes the remaining steps; 

4. identify the Source Access Leg by the dialog identifier present in the Replaces or the Target-Dialog header field 
of the SIP INVITE request; 

5. if a media used in the Source Access Leg session is not offered in the SDP offer of the SIP INVITE request then 
reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps; 

6. if the SIP INVITE request contains a Replaces header field: 

A. follow the procedures defined in IETF RFC 3891 [10] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]; and 

7. send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall 
populate the SIP re-INVITE request as follows: 

A. include a new SDP offer including the media characteristics as received in the SIP INVITE request, by 
following the rules of the 3GPP TS 24.229 [2] . 

Upon receiving the SIP ACK request originated from the SC UE, the SCC AS shall initiate release of the Source Access 
Leg by sending a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]. 



1 6 Roles for collaborative session establishment for 
inter-UE transfer 

16.1 Introduction 

This clause specifies the roles of controller UE, controllee UE and the SCC AS when controller UE transfers media to a 
controllee UE or adds a new media to the controllee UE. 

16.2 SCUE 

1 6.2.1 SC UE procedures for collaborative session establishment by 
transferring media used in an existing session 

1 6.2.1 .1 Controller UE procedures 

To establish a collaborative session by transferring the media component, the controller UE shall send a SIP REFER 
request outside the existing dialog as specified in IETF RFC 3515 [13] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 
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2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the body parameter containing SDP for the media (m=) lines in the session set as follows: 

- media lines that are not being transferred with the port number set to zero 

- media line(s) that are to be transferred containing the port number for the corresponding media received 
in the media line of the SDP received during the last successful SDPoffer answer exchange; 

3) the Accept header field containing the MIME type "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C. 

The controller UE shall handle any response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The controller UE shall save the media information (e.g. 
media line(s) and port number(s)) related to the transferred media(s) received in the sipfrag body of the SIP NOTIFY 
requests in order to perform further inter-UE transfer operations on the controllee UE. When the controller UE receives 
a SIP re -INVITE request from the SCC AS to update the status of the transferred media component after a successful 
transfer, the controller UE shall follow the procedures described in 3GPP TS 24.229 [2], including in the Contact header 
field of the SIP 200 (OK) response the g.3gpp.iut-controller media feature tag as described in annex C. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and continue the existing session. 

1 6.2.1 .2 Controllee UE procedures 

There are no specific procedures for the controllee UE for the collaborative session establishment by transferring media, 
besides the procedures described in 3GPP TS 24.229 [2]. 

1 6.2.2 SC UE procedures for collaborative session establishment with new 
media 

1 6.2.2.1 Controller UE procedures 

The controller UE may establish a collaborative session with a new media at anytime while it has an ongoing IMS 
established session according to 3GPP TS 24.229 [2] with a remote UE. 

The controller UE shall add the new media by sending a SIP REFER request outside the existing dialog as specified in 
IETF RFC 3515 [13] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE; 

NOTE 1: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and other UEs share the same 
public user identity. 

b) the body parameter containing SDP for the media (m=) lines in the session shall be set as follows: 

media lines that are not being transferred with the port number set to zero 

- media lines that are to be added containing the discard port number "9" for the media line(s) to be 
trans fered 

NOTE 2: The discard port number "9" indicates that this port number should be ignored. 
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3) the Accept header field containing the MIME type "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C. 

The controller UE shall handle any response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The controller UE shall save the media information (e.g. 
media line(s) and port number(s)) received in the sipfrag body of the SIP NOTIFY requests in order to perform further 
inter-UE transfer operations on the controllee UE. 

If error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx final 
response, the controller UE shall consider the transfer operation failed and continue the existing session. 

16.2.2.2 Controllee UE procedures 

There are no specific procedures for the controllee UE for the collaborative session establishment by adding media, 
besides the procedures described in 3GPP TS 24.229 [2]. 

1 6.2.3 SC UE procedures for subscription to the session description of a 
collaborative session 

In order to get the information about the changes of session description of the collaborative session, the controller UE 
shall subscribe to the dialog event package for the dialog formed between the controller UE and the SCC AS within 
collaborative session by setting the Target-Dialog header in the SIP SUBSCRIBE request to the associated call-id, 
from-tag, and to-tag and including the event package parameter "include-session-description" according to 
IETF RFC 4235 [48]. The controller UE shall set the expire header of the SIP SUBSCRIBE request to either: 

- zero to receive one subsequent SIP NOTIFY request; or 

- different than zero to receive the subsequent SIP NOTIFY requests. 

When the controller UE receives subsequent SIP NOTIFY requests, the controller UE shall update its information about 
the session description of the collaborative session by the content of that subsequent SIP NOTIFY request. The 
controller UE shall handle response to the SIP SUBSCRIBE request and the possible subsequent SIP NOTIFY request 
according to 3GPP TS 24.229 [2] and IETF RFC 4235 [48]. 

16.3 SCC AS 

1 6.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP REFER requests to provide specific functionality 
relating to call origination: 

1) SIP REFER requests routed to the SCC AS containing: 

a) the SCC AS address in the Request-URI; and 

b) the Refer-To header field including: 

the address of a UE which is neither the UE which sent the SIP REFER request, nor the remote UE, but 
which is within the list of UEs which can be involved within an collaborative session with the UE which 
originated the SIP REFER request; 

zero or more media lines which indicate the port value 0; and 

one or more media lines which indicate the discard port value 9. 

In the procedures below, such SIP REFER requests are called "SIP REFER requests for establishing new media at 
controllee UE". It is assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the 
request from the UE. 
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Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8] . 

Editor's Note: further types of REFER have to be determined. 

1 6.3.2 SCC AS procedures for collaborative session establishment by 
transferring media 

NOTE: If the controller UE is already involved in a collaborative session then the procedures in 
subclause 17.13.1 apply. 

Editor's Note: The text in this first line will need to be aligned with a future change request that will provide the 
procedures for determination of when to invoke this subclause. 

When the SCC AS establishes a collaborative session by transferring media as a result of receiving a SIP REFER 
request from the controller UE , the SCC AS shall send: 

1) a SIP 202 (Accepted) response to the SIP REFER request and a SIP NOTIFY request containing a sipfrag "SIP 
100 Trying" to the controller UE as specified in IETF RFC 3515 [13]; and 

2) a SIP INVITE request to controllee UE, containing: 

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the URI from the P-Asserted-Identity header field of the received 
SIP REFER request; 

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; and 

d) the SDP information for the media component to be transferred as follows: 

The media (m=) lines from the body parameter in the Refer-To header field of the received SIP REFER 
request; and 

for media lines which have non zero port nunmbers the SDP parameters from the corresponding media 
lines as received during the last successful SDPoffer-answer exchange from the remote UE. 

Upon receiving a SIP final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing 
the received final response code in the sipfrag body and if the received response was a SIP 200 (OK) response 
containing an SDP answer then also include in the sipfrag the Content-Type header field from the received 200 (OK) 
response along with the media (m=) lines from the SDP answer. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort 
the media transfer and establishment of the collaborative session. 

If the SIP final response was a SIP 200 (OK) response containing a SDP answer, the SCC AC shall send a SIP re- 
INVITE request on the dialog for the remote leg to the remote UE as sepcified in 3GPP TS 24.229 [2]. The SCC AS 
shall: 

1) send a SIP re-INVITE request containing SDP information as follows: 

a) for the transferred media component(s), set the SDP information as from the SDP answer received in the SIP 
200 (OK) response from the controllee UE; 

b) for all other media components in the collaborative session, include the SDP information as from the original 
session to the remote leg. 

2) send a SIP re-INVITE request to the controller UE following the procedures described in 3GPP TS 24.229 [2] to 
remove the media for the transferred media component. 

Upon receiving a SIP 200 (OK) response with the SDP answer on the remote leg, the SCC AS shall send a SIP ACK 
request on the remote leg. 
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1 6.3.3 SCC AS procedures for collaborative session establishment with 
new media 

When SCC AS receives a SIP REFER request in a new dialog from the contoller UE for establishing a collaborative 
session by adding new media to the controllee UE, the SCC AS shall send: 

1) a SIP 202 (Accepted) response to the controller UE; 

2) a SIP NOTIFY request containing a sipfrag "SIP 100 Trying" as described in IETF RFC 3515 [13] to the 
controller UE; and 

3) SIP INVITE request in accordance to 3GPP TS 24.229 [2] to the controllee UE. The SCC AS shaU construct the 
SIP INVITE request as follows: 

Request-URI set to the SIP URI from the Refer-To header field of the received SIP REFER request; 

includes an SDP offer and sets all the m-lines to zero except the m-line of the media component is to be 
added as the last m-line in the SDP; and 

if the m-line in the received SDP of the SIP REFER request is set to the discard port number "9", the SCC 
AS shall include an a-line set to inactive in the SDP offer. 

Editor's note: The value of c-line is FFS. 

If a SIP non-2xx final response is received from the controllee UE, the SCC AS shall send a SIP NOTIFY request 
including the SIP final response as a sipfrag body to the controller UE and consider the inter-UE transfer operation 
failed. Otherwise, the SCC AS continues with the remainder of the steps described in this subclause. 

Upon receiving a SIP response from the controllee UE with an SDP answer, the SCC AS shall send a SIP re-INVITE 
request to the remote UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct the SDP offer in the SIP re- 
INVITE request as follows: 

1) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

2) the Referred-By header field containing the URI from the P-Asserted-Identity header field of the received SIP 
REFER request; 

3) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; and 

4) the SDP information from the body parameter in the Refer-To header field of the received SIP REFER request 
and for media lines which have non zero port nunmbers the SDP parameters forthe corresponding media lines as 
received during the last successful SDP offer-answer exchange with the remote UE. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort 
the media transfer and establishment of the collaborative session. 

If the SIP final response from the remote UE was a SIP 200 (OK) response with the SDP answer, the SCC AS shall: 

1) send to the remote UE a SIP ACK request; and 

2) send to the controllee UE a SIP re-INVITE request containing the current port number for the media 
component to be added. 

NOTE 1 : Any other changes such as IP address of the remote leg in case remote leg uses different IP addresses for 
different media components can also be updated in the SIP re-INVITE request. 

Upon successful completion of the SDP offer answer exchange using SIP re-INVITE request with the controllee UE, 
the SCC AS shall: 

NOTE 2: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request. 

1) send to the controllee UE a SIP ACK request 
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Editor's note: This is FFS how to inform the controller UE about current port number of the remote UE or any other 
changes such as IP address. 

Upon receiving a SIP final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing 
the received final response code in the sipfrag body and if the received response was a SIP 200 (OK) response 
containing an SDP answer then also include in the sipfrag the Content-Type header field from the received 200 (OK) 
response along with the media descriptions (m=) from the SDP answer. 

1 6.3.4 Procedures to indicate SCC AS establishing a collaborative session 
by adding a new media 

When SCC AS receives a SIP REFER request in a new dialog from the contoller UE with: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; and 

2) the Refer-To header field set to GRUU of a controllee UE and URI parameter containing SDP listing: 

all the media components with associated information in the session; and 

a new media component with associated port number set to the discard port number "9" as the last media 
component, 

the SCC AS shall follow the procedure in subclause 16.3.2 to establish a collaborative session with the controllee UE. 

1 6.3.5 SCC AS procedures for subscription to the session description of a 
collaborative session 

When the SCC AS receives a SIP SUBSCRIBE request with Target-Dialog header field containing the call-id, from- 
tag, and to-tag associated to the dialog between the controller UE and the SCC AS and including the event package 
parameter "include-session-description", the SCC AS shall send session description in SIP NOTIFY requests towards 
the UE according to IETF RFC 4235 [48] . 



1 7 Roles for media transfer within collaborative session 
for inter-UE transfer 

17.1 Introduction 

This clause specifies the roles of the controller UE, the controllee UE and the SCC AS when media transfer from the 
controller UE to a controllee UE or from a controllee UE to another controllee UE within a collaborative session. 

17.2 SCUE 

1 7.2.1 Procedures for controller UE initiated media transfer from controller 
UE to controllee UE 

1 7.2.1 .1 Controller UE procedures 

The SC UE procedures for media transfer from controller UE to a controllee UE is the same as the procedures described 
in subclause 16.2.1.1 with exception that the controller UE additionally sets to the port numbers of the media 
components (in the body header field of the URI in the Refer-To header field of the SIP REFER request) which are 
being used at the controllee UE to values from the corresponding media lines received during the last successful SDP 
offer and answer exchange with the remote party. 
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1 7.2.1 .2 Controllee UE procedures 

There are no specific procedures for the controllee UE for media transfer from controller UE to controllee, besides the 
procedures described in 3GPP TS 24.229 [2]. 

1 7.2.2 Procedures for controller UE initiated media transfer from controllee 
UE to another controllee UE 

17.2.2.1 Controller UE procedures 

To transfer a media component within a collaborative session from one controllee UE to another controllee UE, the 
controller UE shall send a SIP REFER request outside the existing dialog as specified in IETF RFC 3515 [13] and 
include: 

1) the Request-URI set to the Inter UE Transfer SCC AS; 

2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE to which the media m-lines are to be transferred; and 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the body parameter containing SDP for the media m-lines in the session set as follows: 

media lines which are not served by the target controllee UE and which are not being transferred with the 
port numbers set to zero; 

- media lines which are already served by the target controllee UE, therefore are not to be transferred 
containing the port numbers of the remote UE; and 

media lines which are to be transferred containing the port numbers of the remote UE. 

3) the Accept header field containing the MIME type "message/sipfrag"; and 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the collaborative session. 

The controller UE shall handle the subsequent SIP NOTIFY requests to the SIP REFER request according to 
3GPP TS 24.229 [2], IETF RFC 3515 [13]. 

The controller UE shall save the media information (e.g. media line(s) and port number(s)) related to the media(s) 
received in the sipfrag body of the SIP NOTIFY requests in order to perform further inter-UE transfer operations on the 
controllee UE. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and continue the existing session. 

1 7.2.2.2 Controllee UE procedures 

There are no specific procedures for the controllee UE for transferring media form one controllee UE to another 
controllee UE, besides the procedures described in 3GPP TS 24.229 [2]. 

17.3 SCC AS 

1 7.3.1 Procedures for controller UE initiated media transfer from controller 
UE to controllee UE 

The SCC AS procedures for media transfer from the controller UE to a controllee UE is the same as the procedures 
described in subclause 16.3.2 with the exception that upon receipt of a SIP REFER request from the controller UE the 
SCC AS sends a SIP re-INVITE request instead of a SIP INVITE request to the controllee UE. The SIP re-INVITE 
request is within the dialog established when establishing the collaborative session with the controllee UE. 
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1 7.3.2 Procedures for controller UE initiated media transfer from controllee 
UE to another controllee UE 

When the SCC AS maintaining a collaborative session and transferring media as a result of receiving a SIP REFER 
request from one controllee UE to another controllee UE, the SCC AS shall send: 

1) a SIP 202 (Accepted) response to the SIP REFER request and a SIP NOTIFY request containing a sipfrag "SIP 
100 Trying" to the controller UE as specified in IETF RFC 3515 [13] for the dialog on which the SIP REFER 
request was received; and 

2) a SIP re-INVITE request to controllee UE, to which the media component(s) is to be transferred, containing the 
SDP information for the media component to be transferred as follows: 

a) the media descriptions (m) from the body parameter in the Refer-To header field of the received SIP REFER 
request including the associated attributes (a) set to sendonly and the associated bandwidth information (b) 
with RS set to zero and RR set to zero for those media compontents which are to be transferred to the target 
controllee UE; and 

b) for media descriptions (m) which have non zero port numbers the SDP parameters from the corresponding 
media descriptions (m) as received during the last successful SDP offer-answer exchange from the remote 
UE. 

Upon receipt of a 2xx response for the re-INVITE request sent to the controllee UE to which the media component is to 
be transferred, the SCC AS shall: 

1) send a SIP re-INVITE request to controllee UE, from which the media component(s) is to be transferred, 
containing the SDP information for the media component to be transferred as follows 

a) the media descriptions (m) from the body parameter in the Refer-To header field of the received SIP REFER 
request including the associated attributes (a) set to sendonly and the associated bandwidth information (b) 
with RS set to zero and RR set to zero for those media compontents which are to be transferred to the target 
controllee UE; and 

b) for media descriptions (m) which have non zero port numbers the SDP parameters from the corresponding 
media descriptions (m) as received during the last successful SDP offer-answer exchange from the remote 
UE. 

If a 2xx response was received to the re-INVITE request sent to the controllee UE from which the media component(s) 
is to be transferred, the SCC AC shall send a SIP re-INVITE request to the remote UE containing SDP body indicating: 

1) for the transferred media component(s), set the SDP information as received from the SDP answer in the SIP 2xx 
response from the controllee UE to which the media component is to be transferred with the difference that the 
attributes (a) is set to directionality used by the controlee UE from which the media component was transferred; 

2) for all other media components in the collaborative session, include the associated media descriptions (m) as 
from the original session to the remote leg. 

Upon receipt of a 2xx response for the re-INVITE request sent to the remote UE, the SCC AS shall: 

1) if the the transferred media component was the only media component active at the controllee UE from which 
the media component was transferred from, send a SIP BYE request to the controllee UE from which the media 
was transferred from; or 

2) if after the transfer of the media component the controllee UE from which the media was transferred from still 
has other media components within the collaborative session, send a SIP re-INVITE request to the controllee 
UE, from which the media component was transferred, following the procedures described in 

3GPP TS 24.229 [2] and set the port value of the associated media descriptions (m) for the transferred media 
to 0. 

Upon receipt of a 2xx response for the re-INVITE request or the SIP BYE request sent to the controllee UE from which 
the media was transferred the SCC AS shall send a SIP re-INVITE request to the controllee UE to which the media was 
transferred following the procedures described in 3GPP TS 24.229 [2] and setting the attributes (a) associated to the 
transferred media component to its previous status before the inter-UE Transfer operation for the transferred media 
components. 
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Upon receiving a final response to the SIP re-INVITE request which was sent towards the controllee UE to set the 
attributes (a) associated to the transferred media component to its previous status before the inter-UE Transfer operation 
of the transferred media components, the SCC AS shall: 

1) send a SIP NOTIFY request containing the received final response code in the sipfrag body to the controller UE; 

2) if the received response to the SIP re-INVITE is a SIP 2xx response containing an SDP answer, include within 
the sipfrag body 

a) the Content-Type header field from the received SIP 2xx response; and 

b) the SDP answer. 

If any final response to a SIP re-INVITE request (apart from the SIP re-INVITE request which was sent towards the 
controllee UE to set the attributes (a) associated to the transferred media component to its previous status) was a 3xx or 
a 6xx response then the SCC AS shall consider the Inter-UE Transfer operation failed and shall send the SIP NOTIFY 
request to controller UE with the body populated with SIP/2.0 603 Declined. 



1 8 Roles for release of collaborative session for inter-UE 
transfer 

18.1 Introduction 

This clause specifies the roles of controller UE, controllee UE and the SCC AS when controller UE or the remote UE 
releases the collaborative session. 

18.2 SCUE 

1 8.2. 1 Procedures for collaborative session release by controller UE 

18.2.1.1 Controller UE 

There are no specific procedures for the controller UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [2] . 

18.2.1.2 Controllee UE 

There are no specific procedures for the controllee UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [2] . 

1 8.2.2 Procedures for collaborative session release by remote party 

18.2.2.1 Controller UE 

There are no specific procedures for the controller UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [2]. 

18.2.2.2 Controllee UE 

There are no specific procedures for the controllee UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [2] . 
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18.3 SCC AS 

1 8.3. 1 Procedures for collaborative session release by controller UE 

When the SCC AS receives a SIP BYE request from the controller UE for releasing a collaborative session, the SCC AS 
shall send a SIP BYE request according to the procedures described in 3GPP TS 24.229 [2] to the remote UE and to all 
controllee UEs within that collaborative session. 

1 8.3.2 Procedures for collaborative session release by remote party 

When the SCC AS receives a SIP BYE request from the remote party for releasing a collaborative session, the SCC AS 
shall send a SIP BYE request according to the procedures described in 3GPP TS 24.229 [2] to the controller UE and to 
all controllee UEs within that collaborative session. 

1 9 Roles for media adding/deleting within collaborative 
session for inter-UE transfer 

19.1 Introduction 

This clause specifies the roles of the controller UE, the controllee UE and the SCC AS when the controller UE or the 
remote UE adds or releases media to the collaborative session. 

19.2 SCUE 

1 9.2.1 Procedures for adding new media on controllee UE by controller UE 

The SC UE procedures for adding new media to a controllee UE by the controller UE is the same as the procedure 
described in subclause 16.2.2.1 with exception that the controller UE additionally sets the port numbers of the media 
components (in the body header field of the URI in the Refer-To header field of the SIP REFER request) which are 
being used at the controllee UE to values from the corresponding media lines received during the last successful SDP 
offer and answer exchange with the remote party. 

1 9.2.2 Procedures for releasing media on controllee UE by controller UE 

The controller UE may release one or more media components on a controllee UE within a collaborative session while 
it has an ongoing IMS session with a remote UE. 

The controller UE shall release the media by sending a SIP REFER request for releasing media component, including: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the body parameter containing SDP for the media (m=) lines in the session shall be set as follows: 

- media lines that are not being released with their port numbers; and 

- media line(s) that are to be released with the port number set to zero; 

3) the Accept header field set to "message/sipfrag"; 
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4) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 
the dialog between the SCC AS and the controller UE;and 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C. 

The controller UE shall handle SIP response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [2]. The controller UE shall save the media information (e.g. media line number) 
received in the sipfrag body of the SIP NOTIFY request in order to perform further inter-UE transfer operations on the 
controllee UE. 

19.2.2A Procedures for releasing media on controller UE by controller UE 

If the controller UE wants to release a media component on the controller UE within a collaborative session, the 
controller UE shall follow the procedures defined in 3GPP TS 24.229 [2] for removing media with the following 
differences: 

1 . include the SDP information for all other media components within the collaborative session in the SIP re- 
INVITE request; 

2. set all the ports number of the media on the controllee UEs with value zero; and 

3. include the g.3gpp.iut-controller media feature tag as described in annex C in the Contact header field. 

1 9.2.2B Procedures for controller UE to remove a controllee UE from the 
collaborative session 

The controller UE may remove a controllee UE from a collaborative session while it has an ongoing IMS session with a 
remote UE. 

The controller UE shall remove the controllee UE from the collaborative session by sending a SIP REFER request, 
including: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the method parameter set equal to "BYE"; 

3) the Accept header field set to include "message/sipfrag"; and 

4) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 
the dialog between the SCC AS and the controller UE. 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
to 3GPP TS 24.229 [2]. 

1 9.2.3 Procedures for releasing media component by controllee UE 
19.2.3.1 Controller UE 

When controller UE receives a SIP re-INVITE request, it can contain an SDP offer with: 

- media lines already belonging to the controller UE with non-zero port numbers; 

media line(s) belonging to the controllee UE which is releasing the media conponent(s) with non-zero port 
number(s); and 

- media lines belonging to other controllee UEs, with port numbers set to zero. 
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Upon receiving such a SIP re-INVITE request, the controller UE shall follow the procedures described in 
3GPP TS 24.229 [2] to accept or reject the released media component(s) by the controllee UE. 

If the released media component(s) is the only media component(s) used within the collaborative session and the 
controller UE did not accept that media component, the controller UE shall release the collaborative session following 
the procedures described in 3GPP TS 24.229 [2]. 

19.2.3.2 Controllee UE 

There are no specific procedures for the controllee UE for release of media component by controllee UE, besides the 
procedures described in 3GPP TS 24.229 [2]. 

1 9.2.4 Procedures for modifying media on controllee UE by itself 

If the controllee UE wants to modify the characteristics of a media component on itself within a collaborative session, 
the controllee UE shall follow the procedures defined in 3GPP TS 24.229 [2] for modifying media. 

1 9.2.5 Procedures for adding new media by remote UE when the controller 
UE does not alert the user 

When controller UE receives a SIP re-INVITE request within an existing dialog from the remote UE to add a new 
media component on the collaborative session, the controller UE shall decide whether adding the new media on itself or 
adding it to one of its controllee UE. 

If the controller UE decides to add the new media component on itself, the controller UE shall follow the precedure as 
specified in 3GPP TS 24.229 [2], 

If the controller UE decides to add the new media component on one of its controllee UE, the controller UE shall send a 
SIP REFER request outside the existing dialog as specified in IETF RFC 3515 [13] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI;; 

2) the Refer-To header field, including: 

a) the SIP URI of the controllee UE where the media stream should be established from; and 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the body parameter containing SDP for the media (m=) lines for the media lines in the session shall be set as 
follows: 

media lines that are not being transferred with the port number set to zero; 

- media line(s) that are to be added at the controllee UE the same SDP information as in the SIP re-INVITE 
request received from the remote UE. 

3) the Accept header field containing the MIME types "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C. 

The controller UE shall handle a SIP response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [2]. Then the controller UE shall respond to the SIP re-INVITE request with a SIP 200 
(OK) response with a SDP answer as specified in 3GPP TS 24.229[2] including in the Contact header field the 
g.3gpp.iut-controller media feature tag as described in annex C, and construct the SDP information in the SIP 200 (OK) 
response as follows: 

1) set the port number of the new added media component with value zero; and 

2) set all the ports number of the media on the controllee UEs with value zero; and 

3) for other media components on the controller UE are not changed. 
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If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and make a decision again whether adding 
the new media on itself or adding it on other controllee UE. 

1 9.2.6 Procedures for releasing media by remote UE 

Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media 
components are to be released on the controller UE, the controller UE shall release the media component following the 
procedures specified in 3GPP TS 24.229 [2]. 

If the media component to be released is the last media component between the controller UE and the remote party and 
if there are more media components within the collaborative session, the controller UE shall not release the dialog with 
the SCC AS but set the port number(s) associated to the media line(s) to zero. 

If the media component to be released is the last media component in the collaborative session, the controller UE shall 
follow the procedures described in subclause 18.2.1.1. 

19.3 SCC AS 

1 9.3.0 Distinction of requests at the SCC AS 

When SCC AS receives a SIP REFER request within a new dialog from the controller UE with: 

1) the Request-URI set to inter UE transfer SCC AS URI; and 

2) the Refer-To header field set to SIP URI of a controllee UE and URI parameter containing SDP listing: 

- all the media components with associated information in the session; and 

- one or more new media components with associated port number set to the discard port number "9"; 
the SCC AS shall follow the procedure in subclause 19.3.1 to add the media component to the controllee UE. 
When the SCC AS receives a SIP REFER request in a new dialog from the contoller UE with: 

1) the Request-URI set to inter UE transfer SCC AS URI; and 

2) the Target-Dialog header identifies and existing dialog between the SCC AS and the controller UE identified by 
the SIP URI in the Refer-To header field; 

3) the Refer-To header containing the SIP URI of a controllee UE and a URI parameter containing SDP listing: 

- all the media components with associated information in the session; and 

- the media component is to be released with associated port number set to 0. 

then the SCC AS shall follow the procedure in subclause 19.3.2 to release the media component from the controllee UE. 
When the SCC AS receives a SIP REFER request in a new dialog from the contoller UE with: 

1) the Request-URI parameter set to SIP URI of the SCC AS; 

2) the Target-Dialog header identifies and existing dialog between the SCC AS and the controler UE identified by 
the SIP URI in the Refer-To header field; and 

3) the Refer-To header containing the SIP URI of a controllee UE and the method parameter set equal to "BYE"; 

then the SCC AS shall follow the procedure in subclause 19.3.2B to remove the controllee UE.from the collaborative 
session. 
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1 9.3.1 Procedures for adding new media on controllee UE by controller UE 

The SCC AS procedures for adding new media on controllee UE by the controller UE is the same as the procedure 
described in subclause 16.3.3 with exception that upon receipt of SIP REFER request from the controller UE, the SCC 
AS generates a SIP re-INVITE request within the dialog to the controllee UE instead of SIP INVITE request. 

1 9.3.2 Procedures for releasing media on controllee UE by controller UE 

When SCC AS receives a SIP REFER request in a new dialog from the controller UE containing a Refer-To header 
indicating that a SIP re-INVITE request is to be sent to remove one or more media components on a controllee UE, the 
SCC AS shall send: 

1) a SIP 202 (Accepted) response to the controller UE; 

2) SIP NOTIFY request with a sipfrag including SIP 100 (Trying) to the controller UE; 

3) if the remote leg is sending media towards the controllee UE, send a SIP UPDATE request or a SIP re-INVITE 
request towards the remote leg as specified in 3GPP TS 24.229 [2] with the following clarifications: 

- if the controllee UE is sending media, include a "a=sendonly" attribute for the media component to be 
released; 

- if the controllee UE is only receiving media, include a "a=inactive" attribute for the media component to be 
released; 

- include b=RR:0 and b=RS:0 bandwidth modifiers as specified in IETF RFC 3556 [50] for the media 
component to be released; and 

- when the SIP 200 (OK) response to the SIP UPDATE request or the SIP re-INVITE request is received from 
the remote leg the SCC AS shall continue with the next steps; 

NOTE: The steps in 3) are needed to avoid unnecessary ICMP message sending in the underlying IP network due 
to media sent to closed port that could result in the release of the call. The ICMP message is specified in 
IETF RFC 792 [51]. 

5) send a SIP re- INVITE request to the controllee UE, containing an SDP offer changed using the media types 
present in the body parameter in the URI in the Refer-To header. 

Upon receiving a SIP 200 (OK) response from the controllee UE, the SCC AC shall send a SIP re-INVITE request to 
the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re- 
INVITE request as follows: 

1) set port number for removed media component to zero; and 

2) include the SDP information for all other media in the collaborative session as from the original session to the 
remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send: 

1) a SIP ACK request to the remote leg; 

2) upon successful release of the media component, a SIP NOTIFY request to the controller UEcontaining asipfrag 
body that shall include the SIP 200 (OK) response of the SIP re-INVITE request and also include the Content- 
Type header field from the received 200 (OK) response along with the SDP answer received from the controllee 
UE. 

19.3.2A Procedures for releasing media on controller UE by controller UE 

When SCC AS receives a SIP re-INVITE request within an existing dialog from the controller UE to remove a media 

component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 

3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows: 

1) set port number for the removed media component to zero; and 
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2) include the SDP information for all other media in the collaborative session as received during the last successful 
SDP offer-answer exchange from the remote UE. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send: 

1) a SIP ACK request to the remote UE; 

2) a SIP 200 (OK) response to the controller UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct 
the SDP infromation in the SIP 200 (OK) response as follows: 

- set port number for the removed media component to zero; and 

- set all the ports number of the media on the controllee UEs with value zero. 



19.3.2B Procedures for controller UE removing controllee UE from the 
collaborative session 

When SCC AS receives a SIP REFER request in a new dialog from the controller UE containing a Refer-To header 
indicating that a SIP BYE request is to be sent to a controllee UE, the SCC AS shall send: 

1) SIP 202 (Accepted) response to the controller UE; 

2) SIP NOTIFY request with sipfrag including SIP 100 Trying to the controller UE; and 

3) send a SIP BYE request to the controllee UE to release the controlled session in accordance with 
3GPPTS 24.229 [2]. 

Upon receiving SIP 200 (OK) response from the controllee UE, the SCC AC shall send a SIP re-INVITE request to the 
remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re-INVITE 
request as follows: 

1) set port number for removed media component to zero; and 

2) include the SDP information for all other media in the collaborative session as from the original session to the 
remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send: 

1) a SIP ACK request to the remote leg; 

2) upon successful release of the media component, a SIP NOTIFY request to the controller UE containing a 
sipfrag body that shall include the SIP 200 (OK) response of the SIP BYE request. 



1 9.3.3 Procedures for releasing media component initiated by controllee 
UE 

When the SCC AS receives a SIP re-INVITE request from a controllee UE containing an SDP offer with one or more 
media line(s) used on the controllee UE with port number set to zero, where the port number was previously not zero, 
the SCC AS shall send a SIP re-INVITE request towards the controller UE containing an SDP offer with the following 
details: 

1) for the media lines on the controller UE, set the port numbers to the values received during the last successful 
SDP offer and answer exchange with the remote party; 

2) for the media lines on the controllee UE which were offered with port numbers set to zero in the SDP offer 
received in the re-INVITE from the controllee UE, set the port numbers to the values received during the last 
successful SDP offer and answer exchange with the remote party; and 

3) set the port number to zero for the remaining media lines. 

When the SCC AS receives a SIP BYE request from a controllee UE, the SCC AS shall send a SIP re-INVITE request 
towards the controller UE containing an SDP offer with the following details: 



ETSI 



3GPP TS 24.237 version 9.2.0 Release 9 



65 



ETSI TS 124 237 V9.2.0 (2010-04) 



1) for the media lines on the controller UE, set the port numbers to the values received during the last successful 
SDP offer and answer exchange with the remote party; 

2) for the media lines on the controllee UE, set the port numbers to the values received during the last successful 
SDP offer and answer exchange with the remote party; and 

3) set the port number to zero for the remaining media lines. 

Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request from the controller UE and in addition to the 
procedures of 3GPP TS 24.229 [2], the SCC AS shall send a SIP re-INVITE request towards the remote party 
containing an SDP offer with: 

1) all the media lines which were not released by the controllee UE including their port numbers; and 

2) all the media lines which were released by the controllee UE set to the port numbers received in the SDP answer 
contained in the SIP 200 (OK) response from the controller UE. 

Upon receiving the SIP 200 (OK) response from the remote party, and in additon to the procedures of 
3GPP TS 24.229 [2], the SCC AS shall: 

1) if the transaction was initiated by a SIP re-INVITE request, send a SIP 200 (OK) response for the SIP re- 
INVITE request towards the controllee UE containing an SDP answer accepting the SDP offer from the 
controllee UE; or 

2) if the transaction was initiated by a SIP BYE request, send a SIP 200 (OK) response for the SIP BYE request 
towards the controllee UE. 

1 9.3.4 Procedures for modifying media on controllee UE by itself 

When SCC AS receives a SIP re-INVITE request within an existing dialog from the controllee UE to modify a media 

component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 

3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows: 

1) set the modified media information as the same in the SIP re-INVITE request received from the controllee UE; 
and 

2) include the SDP information for all other media in the collaborative session as received during the last successful 
SDP offer-answer exchange from the remote UE. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send: 

1) a SIP ACK request to the remote UE; and 

2) a SIP 200 (OK) response to the controllee UE with the SDP answer only contains the media component on the 
controllee UE. 

1 9.3.5 Procedures for adding new media by remote UE when the controller 
UE does not alert the user 

When SCC AS receives a SIP REFER request from the controller UE to add a new media component on a controllee 
UE, the SCC AS shall send: 

1) SIP 202 (Accepted) response 

2) SIP NOTIFY request containing a sipfig for a SIP 100 (Trying) response to the controller UE as described in 
IETF RFC 3515 [13]; 

3) if the target controllee UE has not been involved in the collaborative session, send a initial SIP INVITE request 
to the controllee UE to add the controlee UE in the collaborative session, containing: 

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the URI from the P-Asserted-Identity header field of the received 
SIP REFER request; 



ETSI 



3GPP TS 24.237 version 9.2.0 Release 9 



66 



ETSI TS 124 237 V9.2.0 (2010-04) 



c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from SIP re-INVITE request received from the remote UE; and 

d) the SDP information for the media component to be transferred as follows: 

- The media (m=) lines from the body parameter in the Refer-To header field of the received SIP REFER 
request; and 

for media lines which have non zero port nunmbers the SDP parameters from the corresponding media 
lines as received in the SDP offer from the remote UE in the SIP re-INVITE request. 

4) if there are other media component within the collaborative session between the target controllee UE and the 
remote UE, send a SIP re-INVITE request to the controllee UE, containing: 

a) the SDP information for the media component to be transferred as follows: 

- The media (m=) lines from the body parameter in the Refer-To header field of the received SIP REFER 
request; and 

for media lines which have non zero port nunmbers the SDP parameters from the corresponding media 
lines as received in the SDP offer from the remote UE in the SIP re-INVITE request 

- for other media components that have already involved in the collabartive session are not changed. 

Upon receiving a SIP final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing 
the received response code in the sipfrag body and if the received SIP response was a SIP 200 (OK) response containing 
an SDP answer then also include in the sipfrag the Content-Type header field from the received SIP 200 (OK) response 
along with the media (m=) lines from the SDP answer. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort 
the media transfer. 

If the SIP final response was a SIP 200 (OK) response containing a SDP answer, the SCC AS shall: 

1) send a SIP ACK request to the controllee UE; 

2) send a SIP 200 (OK) response to the remote UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall 
construct the SDP infromation in the SIP 200 (OK) response as follows: 

- set the same SDP information for the new added media as in the SIP 200 (OK) response received from the 
controlee UE; and 

- include the SDP information for all other media in the collaborative session as received during the last 
successful SDP offer-answer exchange from the remote UE. 

1 9.3.6 Procedures for releasing media by remote UE 

Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media 
components to be released on the controller UE, the SCC AS shall set the port number on the media line(s) which are 
not on controller UE to zero and forward the SIP re-INVITE request towards the controller UE following the 
procedures as specified in 3GPP TS 24.229 [2]. 

Upon receipt from the remote party of a SIP re-INVITE request containing an SDP offer indicating one or more media 
components to be released on the controllee UE, the SCC AS shall: 

if there are more media components left after releasing the selected media components, set the port number on 
the media line(s) which are not on the controllee UE to zero and forward the SIP re-INVITE request; or 

- if there are no more media components left after releasing the selected media components, send a SIP BYE 
request; 

towards the controllee UE following the procedures as specified in 3GPP TS 24.229 [2]. 
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Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media 
components to be released on the controller UE and one or more media components to be released on the controllee 
UE(s), the SCC AS shall: 

- send a SIP re-INVITE request to the controller UE containing the SDP received from the remote end with the 
exception that the port numbers of the media components, not on the controller UE, are set to zero; 

if not all the media component(s) are being released on the controllee UE, send a SIP re-INVITE request to that 
controllee UE, containing the SDP received from the remote end with the exception that the port numbers of the 
media components, not on the controllee UE, are set to zero; and 

- if all the media component(s) are being released on the controllee UE, send a SIP BYE request to the controllee 
UE. 



20 Service continuity and MMTEL interactions 

20.1 Roles for access tranfer and supplementary services 
interaction 

20.1.1 Introduction 

This subclause describes the SCC AS and SC UE procedures for interaction of access transfer when execution of 
supplementary service as described in 3GPP TS 22.173 [24]. 

20.1.2 Originating Identification Presentation (OIP) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIP besides the 
procedures described in 3GPP TS 24.607 [25]. 

20.1.3 Originating Identification Restriction (OIR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIR besides the 
procedures described in 3GPP TS 24.607 [25]. 

20.1.4 Terminating Identification Presentation (TIP) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIP besides the 
procedures described in 3GPP TS 24.608 [26]. 

20.1.5 Terminating Identification Restriction (TIR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIP besides the 
procedures described in 3GPP TS 24.608 [26]. 

20.1.6 Communication Diversion (CDIV) 

Upon receiving an incoming session split across multiple access legs, if the SC UE desires to invoke the CDIV, it may 
choose any of the PS access legs to invoke the call deflection supplementary service following the procedures described 
in 3GPP TS 24.604 [27] or the CS access leg to invoke the call deflection supplementary service following the 
procedures described in 3GPP TS 24.072 [42]. 

NOTE: Communication Forwarding unconditional, Communication forwarding on no reply, Communication 
Forwarding on Busy, Communication Forwarding Not Logged-in and Communication Diversion 
Notification supplementary services are invoked by the CDIV AS as described in 3GPP TS 24.604 [27] 
independent on access type. 
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When the SCC AS which is dividing an IMS session into multiple access legs, receives a CDIV request from the SC UE 
on any access leg, the SCC AS shall terminate any other access legs and invoke the CDIV for that access leg according 
to the procedures described in 3GPP TS 24.604 [27]. 

20.1 .7 Communication Hold (HOLD) 

When the SC UE which is dividing an IMS session through multiple access legs, desires to invoke HOLD on one or 
more media componets, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for PS access 
legs, 3GPP TS 24.083 [43] for a CS access leg not controlled by the II interface or 3GPP TS 24.294 [44] for a CS 
access leg controlled by the II interface which contains the affected media components. 

When the SCC AS which dividing an IMS session into multiple access legs, receives a HOLD request from the SC UE 
or remote end on any access leg, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for that 
access leg. 

20.1.8 Communication Barring (CB) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CB besides the 
procedures described in 3GPP TS 24.61 1 [29]. 

20.1 .9 Message Waiting Indication (MWI) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and MWI besides the 
procedures described in 3GPP TS 24.606 [30]. 

20.1.10 Conference (CONF) 

When the SC UE has multiple access legs and if it wants to send any CONF related requests such as SIP SUBSCRIBE 
request or SIP REFER request, the SC UE may send the request on the PS access leg as describes in 
3GPP TS 24.605 [31] or use the procedures described in 3GPP TS 24.294 [44] for a CS access leg controlled by the II 
interface. For a CS access leg without II interface control the procedures in 3GPP TS 24.084 [47] shall be used to create 
and add participants to a conference. 

When the SC UE has multiple access legs and if it receives a request on one of the access legs for CONF service to 
replace an existing session, the SC UE shall: 

- if each access les is PS access leg, follow procedures specified in 3GPP TS 24.605 [31] to establish a new 
session to the conference focus; 

- if the CS access leg is not controlled by the II interface follow the procedures in 3GPP TS 24.008 [45] for 
releasing and establishing a new call towards the conference focus; and 

- if the CS access leg is controlled by the II interface follow the procedures in 3GPP TS 24.294 [44] for establish 
a new session towards the conference focus. 

When the SC UE has multiple access legs and if it receives a request on one the access legs for CONF service to replace 
an existing session outside the dialog, the SC UE shall follow procedures specified in 3GPP TS 24.605 [31] to establish 
a new session to the conference focus. 

When the SC UE has multiple access legs and if the remote UE sends a request for the CONF servive to replace an 
existing session within the same dialog, the SCC AS shall deliver the request for CONF service on the Gm controlled 
any of access legs or over the II interface if II interface control is used or to the CS leg if only a CS leg exists, to the SC 
UE. 

20.1 .1 1 Explicit Communication Transfer (ECT) 

When the SC UE has multiple access legs and if it acts as the transferor UE, the SC UE may send the request for ECT 
service on any of the PS legs as specified in 3GPP TS 24.629 [32], or on the CS access leg not controlled by the II 
interface follow the procedures in 3GPP TS 24.091 [46] and on a CS access leg controlled by the II interface follow the 
procedures in 3GPP TS 24.294 [44]. 
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When the SC UE has multiple access legs and if it acts as the transferee UE, the SCC AS may deliver the request for 
ECT service on any of the access legs. 

NOTE: Delivering of the request towards the CS access leg may be controlled by operator policy. 

When the SC UE has multiple access legs and if it receives an ECT request on one of the access legs, the SC UE shall 
follow the procedures specified in 3GPP TS 24.629 [32] to establish a new session to the Transfer Target. 

20. 1 . 1 2 Advice of Charge (AOC) 

When the AOC service as specified in 3GPP TS 24.647 [33] is active and if the SC UE has multiple access legs, the 
SCC AS may deliver charging information during the communication to the SC UE over any of the access legs which 
accept application/vnd.etsi.aoc+xml MIME type. 

20.1.13 Closed User Groups (CUG) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CUG besides the 
procedures described in 3GPP TS 24.654 [34]. 

20.1.14 Three-Party (3PTY) 

The 3PTY service is considered as a special case of CONF service in 3GPP TS 24.605 [31] and the interaction with 
session transfer is the same as that specified in subclause 20.1.10 for CONF service. 

20.1.15 Flexible Alerting (FA) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and FA besides the 
procedures described in 3GPP TS 24.239 [35]. 

20.1 .1 6 Communication Waiting (CW) 

Upon receiving an incoming session split across multiple access legs if the SC UE desires to invoke the CW, it may 
choose any of the access legs to invoke the CW service following to the procedures defined in 3GPP TS 24.615 [36]. 

When the SCC AS which is dividing an IMS session into multiple access legs, receives a CW request from the SC UE 
on any access leg, the SCC AS shall invoke the CW service following the procedures defined in 3GPP TS 24.615 [36]. 

20.1 .1 7 Completion of Communications to Busy Subscriber 
(CCBS)/Completion of Communications by No Reply (CCNR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CCBS/CCNR 
besides the procedures described in 3GPP TS 24.642 [37]. 

20. 1 . 1 8 Customized Alerting Tones (CAT) 

There are no specific procedures for the SC UE and the SCC AS for CAT besides the procedures described in 
3GPP TS 24.182 [38]. 

20.1.19 Malicious Communication IDentification (MCID) 

When invoking the MCID service in temporary subscription mode and there are multiple active access legs for the 
session, the SC UE may send the SIP re-INVITE request for invoking MCID service as defined in 3GPP TS 24.616 [39] 
on any of the access legs. 
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20.1.20 Reverse Charging 

The interaction of the Reverse Charging service according to 3GPP TS 24.647 [33] with access transfer is not specified 
in this version of the specification. 

20.1 .21 Personal Network Management (PNM) 

The interaction of the PNM service according to 3GPP TS 24.259 [40] with access transfer is not specified in this 
version of the specification. 

20.1.22 Customized Ringing Signal (CRS) 

The interaction of the CRS service according to 3GPP TS 24.183 [41] with access transfer is not specified in this 
version of the specification. 

20.2 Roles for inter-UE transfer and supplementary services 
interaction 

20.2.1 Introduction 

This subclause describes the SCC AS and SC UE procedures for inter-UE transfer when execution of supplementary 
service as described in 3GPP TS 22.173 [24]. 

20.2.2 Originating Identification Presentation (OIP) 

There are no specific procedures for the SC UE and the SCC AS for OIP besides the procedures described in 
3GPPTS 24.607 [25]. 

20.2.3 Originating Identification Restriction (OIR) 

There are no specific procedures for the SC UE and the SCC AS for OIR besides the procedures described in 
3GPP TS 24.607 [25]. 

20.2.4 Terminating Identification Presentation (TIP) 

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 
3GPPTS 24.608 [26]. 

20.2.5 Terminating Identification Restriction (TIR) 

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 
3GPPTS 24.608 [26]. 

20.2.6 Communication Diversion (CDIV) 

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 
3GPPTS 24.604 [27]. 

20.2.7 Communication Hold (HOLD) 

The controller UE may hold an active media component(s) on itself, by following the procedures for HOLD described 
in 3GPPTS 24.610 [28]. 

The controller UE may hold or resume an active media component(s) on a controllee UE within a collaborative session 
while it has an ongoing IMS session with a remote UE, by sending a SIP REFER request and including: 
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1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the body parameter containing SDP for the media m-lines in the session shall be set as follows: 

- media lines that are not on the controllee UE with port number zero; 

- media lines that are on the controllee UE and are not to be changed with their current directionality and 
the current port number from the remote end; and 

- media lines that are on the controllee and: 

- if those media lines are to be held, set a-line to inactive or recvonly and the current port number from 
the remote end; or 

- if those media lines are to be resumed, set a-line to sendonly or sendrecv and the current port number 
from the remote end. 

3) the Accept header field set to "message/sipfrag"; and 

4) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 
the collaborative session. 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
to3GPPTS24.229[2]. 

When SCC AS receives a SIP REFER request from the controller UE to hold or resume a media component on a 
controllee UE, the SCC AS shall send: 

1) a SIP 202 (Accepted) response for the SIP REFER request to the controller UE; 

2) a SIP NOTIFY request with sipfrag including SIP 100 Trying to the controller UE; and 

3) send a SIP re- INVITE request to the controllee UE, containing an SDP offer as received from remote UE in the 
previous offer/answer exchanged and with directionality as set for the corresponding media in the "body" header 
of the URI in the Refer-To of the SIP REFER request received from the controller. 

Upon receiving SIP 200 (OK) response from the controllee UE, the SCC AC shall send: 

1) a SIP NOTIFY request to the controller UE with the sipfrag body including the SIP 200 (OK) response of the 
SIP re-INVITE request and also include the SDP information received from the controllee UE. 

2) a SIP re-INVITE request to the remote leg as specified in 3 GPP TS 24.229 [2]. The SCC AS shall construct the 
SDP information in the SIP re-INVITE request as follows: 

- set the SDP information including the directionality as received in the SIP 200 (OK) response from the 
controlee UE; and 

include the SDP information for all other media in the collaborative session as from the original session to 
the remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send a SIP ACK 
request to the remote leg; 

When a controllee UE receives a SIP re-INVITE request to hold a media component(s), it shall follow the procedures 
described in 3GPP TS 24.610 [28]. 
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20.2.8 Communication Barring (CB) 

There are no specific procedures for the SC UE and the SCC AS for CB besides the procedures described in 
3GPPTS 24.611 [29]. 

20.2.9 Message Waiting Indication (MWI) 

There are no specific procedures for the SC UE and the SCC AS for MWI besides the procedures described in 
3GPPTS 24.606 [30]. 

20.2.10 Conference (CONF) 

In a collaborative session, it shall only be possible for the controller UE to invoke the CONF service following the 
procedures as described in 3GPP TS 24.605 [31]. 

When the remote UE sends a request for the CONF service to replace an existing collaborative session, the SCC AS 
shall deliver the request for CONF service to the controller UE, which then sets up new session following the 
procedures described in 3GPP TS 24.605 [31]. 

20.2.1 1 Explicit Communication Transfer (ECT) 

In a collaborative session, it shall only be possible for the controller UE to invoke ECT service following the procedures 
as described in 3GPP TS 24.629 [32]. 

When the controller UE receives a notification that ECT has been performed successfully, the controller UE shall 
terminate the previous active session with the transferee UE by terminating all related media control sessions on the 
controllee UEs. 

When the SCC AS receives an ECT transfer request from the remote end to transfer the collaborative session, the SCC 
AS shall deliver the request to the controller UE. 

When the controller UE receives an ECT transfer request to transfer the collaborative session, the controller UE shall 
establish a new session towards the transfer target following the procedures described in 3GPP TS 24.629 [32]. 

20.2.12 Advice of Charge (AOC) 

When the AOC service specified in 3GPP TS 24.647 [33] is active, the SCC AS shall deliver charging information to 
the controller UE. 

20.2.13 Closed User Groups (CUG) 

There are no specific procedures for the SC UE and the SCC AS for CUG besides the procedures described in 
3GPP TS 24.654 [34]. 

20.2.14 Three-Party (3PTY) 

The 3PTY service is considered as a special case of CONF service in 3GPP TS 24.605 [31] and the interaction with 
inter-UE transfer is the same as that specified in subclause 20.2.10 for CONF service. 

20.2.15 Flexible Alerting (FA) 

There are no specific procedures for the SC UE and the SCC AS for FA besides the procedures described in 
3GPPTS 24.239 [35]. 

20.2.16 Communication Waiting (CW) 

There are no specific procedures for the SC UE and the SCC AS for CW besides the procedures described in 
3GPPTS 24.615 [36]. 
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20.2.1 7 Completion of Communications to Busy Subscriber 

(CCBS)/Completion of Communications by No Reply (CCNR) 

There are no specific procedures for the SC UE and the SCC AS for CCBS/CCNR besides the procedures described in 
3GPP TS 24.642 [37]. 



20.2.1 8 Customized Alerting Tones (CAT) 

There are no specific procedures for the SC UE and the SCC AS for CAT besides the procedures described in 
3GPPTS 24.182 [38]. 

20.2.19 Malicious Communication IDentification (MCID) 

There are no specific procedures for the SC UE and the SCC AS for MCID besides the procedures described in 
3GPPTS 24.616 [39]. 



20.2.20 Personal Network Management (PNM) 

There are no specific procedures for the SC UE and the SCC AS for PNM besides the procedures described in 
3GPPTS 24.259 [40]. 

20.2.21 Customized Ringing Signal (CRS) 

There are no specific procedures for the SC UE and the SCC AS for CRS besides the procedures described in 
3GPPTS 24.183 [41]. 
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Annex A (informative): 
Example signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for Service Continuity based on the Session Initiation Protocol (SIP) and 
SIP Events. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.237 [9]. 

A.2 Introduction 
A.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [3]. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [3] subclauses 4.1 and 4.2 applies with the additions 
specified below: 

- tel:+l-237-555-l 1 1 1 represents the public user indentity of SC UE A. 

- tel:+l-237-555-2222 represents the public user indentity of UE B. 

- sip:sccasl. homel.net represents the Internet host of SCC AS. 

sip:interUEtransfer@sccasl. homel.net represents the Inter UE Transfer SCC AS URI of the UA A. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [3]. 

However, 3GPP TS 24.228 [3] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [3], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [3] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A.2-1 is used. 
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INVITE 

► SIP message 

SETUP 

► CS message 




Media over a PS connection 



Media over a CS connection 



Figure A.2-1 : Signalling flow notation 

A.3 Signalling flows for registration 
A.3.1 Introduction 

When using CS access for media and to make use of the ISC procedures, the SC UE is registered in IM CN subsystem 
and the signalling flows are defined in 3GPP TS 24.292 [4] subclause A. 2. 

When initiating a CS call, the SC UE can be registered in the CS domain as defined in 3GPP TS 24.008 [8]. 

Whenever the UE acquires IP connectivity via an IP-CAN, the signalling flows for registration in the IM CN subsystem 
are defined in 3GPP TS 24.228 [3]. 

A.3. 2 Signalling flows for multiple registration for service 
continuity 

The signalling flows shown in figure A. 3. 2-1 gives an example when a UE connects to different IP-CAN respectively 
and performs multiple registrations. In this example the UE also supports the Controller UE procedures for IUT 
transfer. In this example the SCC AS receives the registration state information that it needs to implement SCC specific 
requirements from the third-party SIP REGISTER request. 
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UE 



— 1. SIP Register#l- 



P-CSCF#1 



-6. 200 OK- 



9.UE connects to a 
new IP-CAN 



P-CSCF#2 



I-CSCF 



-2. SIP Register#l- 



-5. 200 OK- 



0. SIP Register#2- 



-15. 401 Unauthorized- 



I 



-16. SIP Register#2- 



-21.200 OK- 



11. SIP 
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14. 401 
Unauthorized 

17. SIP 

Register#2 



»20. 200 OK- 



S-CSCF 



3. SIP 
Register#l 
-4. 200 OK- 



12. SIP 
Register#2 
13.401 
Unauthorized 



18. SIP 

Register#2 
-19. 200 OK- 



SCC AS 



-7. SIP Registers 
«-8. 200 OK— 



-22. SIP Register^ 
«-23. 200 OK — 



Figure A.3.2-1 Signalling flows for multiple registrations 

1. SIP REGISTER request (UE to P-CSCF#1)-See example in table A.3.2-1 

UE sends the SIP REGISTER request via the IP-CAN#1. 
NOTE 1: For clarity, the unprotected SIP REGISTER request via the IP-CAN#1 is not shown in this example. 

Table A.3.2-1SIP REGISTER request (UE to P-CSCF#1) 



REGISTER sipiregistrar.homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max- Forwards : 70 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
From : <sip : userl_publicl@homel . net > ; tag=4f a3 
To : <sip : userl_publicl@homel . net> 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; reg-id=l; +sip . instance= " < 
urn : gsma : imei :90420156-025763-0 >";+g. 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . access type= " cellularl " ; expires=6000 
; +g . 3gpp . iut -controller 
Call -ID : apb0 3a0s0 9dkjdfglkj4 9111 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 
nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl -MD5 , 
uri=" sip: registrar .homel .net" , response= " 662 9f ae4 93 93a053 9745 097 85 07c4ef 1 " 

Security-Client: ipsec-3gpp; alg=hmac- sha- 1- 96 ; spi-c=23456789 ; spi-s=12345678 ; port-c=2468 ; 
port-s=1357 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi -s =8765432 1 ; port- 

c=8642; port-s=7531 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 2 REGISTER 
Supported: path, outbound, gruu 
Content-Length: 
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1. SIP REGISTER request (P-CSCF#1 to I-CSCF)-See example in table A.3.2-2 

After performing the DNS query, the P-CSCF#1 forwards the SIP REGISTER request towards I-CSCF. The P- 
CSCF adds a Path header field with a flow token and includes the 'ob' parameter 



Table A.3.2-2 SIP REGISTER request (P-CSCF#1 to l-CSCF) 



REGISTER sipiregistrar.homel.net SIP/2.0 




Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 




[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 




Max-Forwards: 69 




P-Access-Network-Info : 




Path: <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl .net; lr;ob> 




Require: path 




P-Visited-Network- ID : "Visited Network Number 1" 




P -Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 




From : 




To : 




Contact : 




Call-ID: 




Authorization: Digest username="userl private@homel.net", realm= " registrar . homel . net " , 


nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl -MD5 , 




uri=" sip: registrar .homel .net" , response= " 662 9f ae4 93 93a053 9745097 85 7c4ef 1 " 


integrity- 


protected= "yes " 




CSeq: 




Supported : 




Content-Length : 





2. SIP REGISTER request (I-CSCF to S-CSCF) 

The I-CSCF forwards the SIP REGISTER request to the S-CSCF. 

3. SIP 200 (OK) response (S-CSCF to I-CSCF)-See example in table A.3.2-4 

The S-CSCF sends a SIP 200 (OK) response to the I-CSCF indicating that Registration was successful. AS the 
URI in the first Path header field has an "ob" URI parameter, it include a Require header field with the option- 
tag "outbound". 

Table A.3.2-4: SIP 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net ;branch=z 9hG4bK24 Of 34 . 1 , SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Path : <sip : termOpcscf 1 . visitedl . net ; lr ; ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From: 
To : 

Call-ID: 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 

pub-gruu= " sip : userl_publicl@homel .net; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91e6bf 6 " 

; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f aj sc7 - aj d6f abzOf 8g5@example . com; gr 11 

; +sip . instance= " < urn : gsma : imei :90420156-025763-0 >"+g. 3gpp .icsi-ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . accesstype="cellularl " 

; expires=600000 ; +g . 3gpp . iut-controller 

CSeq: 

Supported: path, outbound 
Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel . net > , <sip : userl_public3@homel . net> , <sip:+l-212- 

555 - llll@homel . net ; user=phone> 
Content-Length : 



5-6. SIP 200 (OK) response (I-CSCF to UE) 

The I-CSCF forwards the SIP 200 (OK) response to the UE via P-CSCF#1. 
7. SIP REGISTER request (S-CSCF to SCC AS)-See example in table A.3.2-7 
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After UE successfully registered in the IM CN subsystem, the S-CSCF sends a third party SIP REGISTER 
request to the SCC AS based on the initial filter criteria it received. 

Table A.3.2-7: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2 . 

Via: SIP/2. 0/UDP scscf 1 .homel . net ;branch=z9hG4 99f fhy 
Max- Forwards : 70 

From: <sip : scscf 1 . homel . net> ; tag=538ya 
To : <sip : userl_publicl@homel . net> 
Call-ID: lasdaddlrf jflslj40a222 

P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Contact: <sip : scscf 1 . homel . net> ; expires=6 
CSeq: 87 REGISTER 

Content - Type : mult ipart /mixed ; boundary= " boundaryl " 
Content-Length: (...) 

- -boundaryl 

Content-Type: message/sip 

REGISTER sip: registrar. homel. net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Path: <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl . net ; lr ;ob> 
Require: path 

P-Visited-Network- ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
From : <sip : userl_publicl@homel . net > ; tag=4f a3 
To : <sip : userl_publicl@homel . net> 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; reg-id=l; +sip . instance= " < 
urn : gsma : imei :90420156-025763-0>";+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi .mmtel" ; +g . 3gpp . ics= "principal " ;+g . 3gpp . accesstype="cellularl";expires=600000 ; +g . 3gpp . 
iut- controller 

Call -ID: apb03a0s09dkjdfglkj4 9111 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 

uri=" sip : registrar .homel .net" , response= " 6 62 9f ae4 9393a053974 50 97850 7c4ef 1 " 

CSeq: 2 REGISTER 

Supported: path, outbound, gruu 

Content-Length: 

- -boundaryl 

Content-Type: message/sip 
SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p .homel .net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net ; branch=z9hG4bK24 Of 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Path : <sip : termOpcscf 1 . visitedl . net ; lr ; ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From : <sip : userl_publicl@homel . net > ; tag=4f a3 
To : <sip : userl_publicl@homel . net> ; tag=3ecl 
Call -ID: apb03a0s0 9dkjdfglkj4 9111 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 

pub-gruu= " sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91e6bf 6 " 

; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f aj sc7-a j d6f abzOf 8g5@example . com; gr " 

; +sip . instance= " < urn : gsma : imei :90420156-025763-0>" ;+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal "+g . 3gpp . accesstype="cellularl " 

; expires=600000 ; +g . 3gpp . iut-controller 

Supported: path, outbound 

Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel . net > , <sip : userl_public3@homel . net > , <sip:+l-212-555- 
llllohomel . net ;user=phone> 
CSeq: 2 REGISTER 
Content-Length: 

- - boundaryl - - 



8. SIP 200 OK response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third party SIP REGISTER request. 
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9. UE connects to a new IP-CAN 

The UE connects to a new IP -CAN and will perform the registration via the new IP-CAN. 

10. SIP REGISTER request (UE to P-CSCF#2)- See example in table A.3.2-10 

UE sends the unprotected SIP REGISTER request via the new IP-CAN to P-CSCF+2 which in this example is a 
different one with previous registration. 

Table A.3.2-10: SIP REGISTER request (UE to P-CSCF#2) 



REGISTER sipiregistrar.homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : eee] ; comp=sigcomp ;branch=z9hG4bKnasiuen8 
Max-Forwards: 70 

P-Access-Network-Info : IEEE-802 . lib 

From : <sip : userl_publicl@homel . net > ; tag=2hiue 

To : <sip :userl_publicl@homel . net> 

Contact: <sip : [5555 :: aaa :bbb : ccc : eee] ; comp=sigcomp> ; reg-id=2; +sip . instance= " < 
urn : gsma : imei :90420156-025763-0>;+g. 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 

service . ims .icsi .mmtel 11 ; +g . 3gpp . ics= "principal 11 ; +g . 3gpp . access type="wlan2";expires=600000 ; + 
g . 3gpp . iut -controller 
Call-ID: E05133BD26DD 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 

nonce="", uri= " sip : registrar . homel . net " , response="" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789 ; spi-s=12345678 ; port-c=1234 ; 

port-s=5G78 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 1 REGISTER 
Supported: path, outbound, gruu 
Content-Length: 



11-12. SIP REGISTER request (P-CSCF#2 to S-CSCF) 

The P-CSCF forwards the SIP REGISTER request towards S-CSCF via I-CSCF. Likewise in message #2, P- 
CSCF#2 adds a Path header field with flow token and 'ob' parameter. 

13-15. SIP 401 (Unauthorized) response (S-CSCF to UE) 

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 
16-18. SIP REGISTER request (UE to S-CSCF) 

The UE sends the protected SIP REGISTER request towards S-CSCF using contact#2. 
19-21. SIP 200 (OK) response (S-CSCF to UE) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 
22. SIP REGISTER request (S-CSCF to SCC AS) 

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received. 
Table A.3.2-22: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2.0 

Via: SIP/2. 0/UDP scscfl .homel .net, -branch=z9hG499ffhy 
Max-Forwards: 70 

From: <sip : scscfl . homel . net> ; tag=538ya 
To : <sip :userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Call-ID: lasdaddlrf jflslj40a222 

Contact: <sip : scscfl . homel . net> ; expires=600000 
CSeq: 87 REGISTER 

Content - Type : mul t ipart /mixed ; boundary= " boundaryl " 
Content-Length: (...) 

- -boundaryl 

Content-Type: message/sip 

REGISTER sip : registrar . homel . net SIP/2.0 
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Via : SIP/2 . 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK24 0f 34 .1, SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : eee] : 1357 ; comp = sigcomp ; branch=z9hG4bKnashds7 




Max- Forwards : 6 9 




P- Access -Network- Info : IEEE- 8 02 . lib 




Path : <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl . net ; lr;ob> 




Require : path 




P - Vi s i t ed-Net work- ID : "Visited Network Number 1" 




p _ Pharni nn-Vprlrir • iriH -\r^ 1 hp-" ATrr-pf-^/TTflHrri-i- £09 T rTRt AP'rViRT.^n— D9^RR1 fl 9 _1 " 
c ^_ic*.__y__i_y vcL-.L_.wi_ ■ __.<_*__. \jl v ai. uc — r\ y i cl y u u \_iillt^ o w__ jl j_ ± _j i__r__7 __ j_j_t__i __ «_j — u___>_j_j_lu__*± 




From : <sip:iiserl p ubl ic l@homel . net> ; tacj=2hiu.e 




To : <sip:iiserl pu.blicl@homel . net> 




Contact: <sip: [5555: :aaa:bbb:ccc:eee] ; comp= s icjcomp > ; recj - id=2 ; + sip . instance 


= " < 


urn : cj sma : ime i : 90420156 — 025763 — 0> / +cj ■ 9PP ■ icsi — ref = " urn's 3Aurn — 7 "6 3 cjpp — 




s ervi c e . ims . icsi . mmt e 1 " ,* +cj . 3 cjpp - ics = " principal" ; . 3 CJPP - access type 




= "wlan2":expires = 600000;+g. 3qpp . iut- controller 




Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 




Authorization: Digest username="userl private@homel.net", realm="registrar 


. homel . net " , 


nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 




uri="sip : registrar .homel .net" , response= " 6 62 9f ae4 9393a0 53974 50978507c4ef 1 " 




CSeq: 3 REGISTER 




Supported: path, outbound, gruu 




Content-Length: 




- -boundaryl 




Content-Type: message/sip 




SIP/2.0 200 OK 




Via: SIP/2. 0/UDP icscfl p . homel . net ; branch=z9hG4bK351g45 . 1 , SIP/2 . 0/UDP 




pcscf 1 .visitedl . net ;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : eee] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 




Path : <sip : termOpcscf 1 . visitedl . net ; lr ; ob> 




Service-Route : <sip : origOscscf 1 . homel . net ; lr> 




From: <sip:userl publiclohomel . net> ; tag=2hiue 




To: <sip:userl publiclohomel . net> ; tag=2da87 




Call -ID: apb03a0s0 9dkjdfglkj4 9111 




Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 




pub-gruu= " sip : userl publiclohomel . net ; gr-urn : uuid : f 81d4f ae- 7dec- lldO -a765- 


00a0c91e6bf 6" 


; temp-gruu= " sip : tgruu . 7hs = = j d7vnzga5w7f a j sc7-a j d6f abzOf 8g5©example . com; gr " 




; +sip . instance= " <urn : gsma : imei :90420156-025763-0>";+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 


service . ims . icsi .mmtel" ; +g . 3gpp . ics= "principal " ; +g . 3gpp . accesstype="wlan2" 




; expires=600000 ; +g . 3gpp . iut-controller 




Supported: path, outbound 




Require : outbound 




Date: Wed, 11 July 2001 08:49:37 GMT 




P-Associated-URI : <sip:userl public20homel.net>, <sip :userl_public3©homel . 


net>, <sip : +1-212-555- 


llllohomel . net ;user=phone> 




CSeq: 3 REGISTER 




Content-Length: 




- - boundaryl - - 





23. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request. 



A. 4 Signalling flows for call origination for service 
continuity 

A.4.1 Session origination for CS calls 

An example flow for session origination for CS calls can be found in 3GPP TS 24.292 [4]. 
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A. 5 Signalling flows for call termination for service 
continuity 

A. 5.1 Session termination using CS media 

An example flow for session termination using CS calls can be found in 3GPP TS 24.292 [4]. 

A.6 Signalling flows for PS-CS access transfer 
A.6. 1 PS-CS access transfer: CS-PS 

In this example, SC UE A has an ongoing session with remote UE B over CS bearer before access transfer. When SC 
UE connects to an IP-CAN, it decides to transfer the session over the new IP-CAN. 
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SCUE A 


cs 


PS 









Interworking 
entities 



Intermediate IM 
CN subsystem 
entities 



SCC AS 



UEB 



1 . SC UE A is on an active session with UE B. Call is anchored at SCC AS. 



1 a.CS bearer- 



2. UE A connects to a new IP-CAN 
and decides to transfer the session 
over the new IP-CAN. It reserves 
resources in the new IP-CAN. 



■lb. IP bearer- 



-3. INVITE- 



4. iFC Evaluation 



—5. SIP INVITEH 



-14. SIP 200 (OK) INV it^ 
I 

15. SIP ACK 



I 20. DISCONNECT 

[-21. RELEASE 1 

122. RELEASE COMPLETE- 



I 



■17. IP bearer- 



-19. SIPBYE- 



-23. SIP 200 (OK)- 



6 Remote leg Update 



7. SIP 
' relNVITE 



-8. SIP relNVITE- 



I 9. SIP 200 (OK) reINV mr 

10. SIP 
200 (OK) reINV iTE* 
«-l 1 . SIP ACK — 
12. SIP ACK- 



13. SIP 
L200 (OK) INVITE 



-16. SIP ACK- 



-18. SIPBYE- 



-24. SIP 200 (OK> 



Figure A.6.1-1 : Signalling flow for PS-CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the session over the new IP -CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) - see example in table A.6.1-3 

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing call. 
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Table A.6.1-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain. xferOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route: <sip : pcscfl . homel . net : 7531 ; lr >, <sip : origOscscfl . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 902 3 7 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip :userl_publicl@homel . net ; gr= urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.6.1-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 
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Table A.6.1-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :userl_publicl@homel . net ;gr=urn :uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; lr > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net > , <tel : +l-237-555-llll> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= " AyretyU0dm+6O2IrT5tAFrbHLso=02 3 5 51024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net > ; tag=1717777 

To: <tel : +l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip :user2_publicl@home2 . net ;gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5 5 5 5 : : aaa : bbb : ccc : ddd 
s = 

c = IN IP6 5555: : aaa: bbb: ccc : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
17. Media paths between UE A and UE B 

The media path is using the new IP-CAN. 
18-19. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 

20-22. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 
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23-24. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 

A.6.2 PS-CS access transfer: PS-CS 

In this example, SC UE A has an ongoing session with remote UE B over PS bearer before access transfer which is 
anchored at SCC AS. When the SC UE attaches to the CS domain, it decides to transfer the session over the CS bearer 
without ICS capability. 
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Figure A.6.2-1 Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A is on an active session with UE B: 

There is an ongoing IP bearer between the SC UE and the remote end UE B. The call is achored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the session over the CS bearer. 
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3. CC SETUP messages 

The SC UE sends the CC SETUP message with the static STN as the called party number. 

4. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
table A.6.2-4 

Table A.6.2-4: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ; branch=z9hG4bk731b87 
Max-Forwards: 70 

Route : <sip : icscf 1 . homel . net ; lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel: +1-237- 555 - 1111> ; tag=171828 
To: <tel: +l-237-555-3333> 
Call- ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Accept -Contact : * ; +g . 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel" 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mgcf 1 . homel . net ; gr> ; +g . 3gpp .icsi-ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.6.2- 
8 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.6.2-8: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip :user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf=[5555::b9 9:c88:d7 7:e66]; ccf = [5555 : :a55 :b44 : c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value= "BzyretyU0dm+6O2IrT5tAFrbHLso=023551034 " ; orig- 

ioi= " type3homel . net " 
Privacy: none 

From: <tel: +1-23 7- 555 - 1111> ; tag=569812 
To: <tel : +l-237-555-2222>; tag=26545 
Call- ID: ddl3a0s0 9a2sdfglkj 490378 
Cseq : 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 

00a0c91e6bf 6> ; +g . 3gpp . icsi-ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow : 

Content-Type: Content-Length: 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVPF 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
m=message TCP/MSRP 98 
a=accept-types : text/plain 



9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via EVI CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

16. CC CONNECT message (interworking entities to SC UE A) 

17. CC CONNECT ACKNOWLEDGE message (SC UE A to interworking entities) 
18-19. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 
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The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearer is still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a SIP BYE request to 
the IT-: A. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

25. Media paths between SC UE A and UE B 

Finally, the session is transferred from PS bearer to CS bearer. 



A.7 Signalling flows for PS-PS access transfer 
A. 7.1 Introduction 

The signalling flows for PS-PS access transfer demonstrate how a multimedia session is transferred from Source Access 
Leg to the Target Access Leg. The following signalling flows are included: 

- subclause A. 7. 2 shows an example when all media of an ongoing communication session and the associated 
signalling are transferred from Source Access Leg to the Target Access Leg; and 

- subclause A.7. 3 shows an example when not all media of an ongoing communication session are transferred 
from the Source Access Leg to the Target Access Leg. 



A. 7. 2 PS-PS access transfer with full media transfer 

The signalling flows shown in figure A.7. 2-1 describes the PS-PS access transfer procedure when all media of an 
ongoing communication session and the associated signalling are transferred from one contact address of an UE to a 
different contact address of the same UE. No lower-level mechanism to support the access transfer is assumed or 
needed. 

In this example the UE-1 is on an active multimedia session with the UE-2 via one IP-CAN. After changing to a new 
IP -CAN, obtaining a new IP address, and discovering a P-CSCF, the UE-1 reserves resources in new IP -CAN prior to 
initiating the PS-PS access transfer procedure. When the PS-PS access transfer procedure is completed, the UE-1 
continues the multimedia session with the UE-2 on the new IP -CAN. In this example, when attaching to the new IP- 
CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that the UE-1 and the IM CN subsystem support simultaneous multiple 
registrations and requires that the UE-1 supports dual mode operation. 

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of 
the Call-ID, From tag, and To tag. 
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Figure A.7.2-1 : Signalling flow for session handover 

NOTE 3: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

The UE-1 is in an active session with the UE-2. The call is anchored in the SCC AS. It is irrelevant which 
endpoint initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg 
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over old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=774321". The UE-1 and UE-2 exchange media over the old IP-CAN, which is maintained while the UE-1 
initiates the handover procedure. 

2. UE-1 connects to new IP-CAN 

The UE-1 determines that a handover of the session is required. The UE-1 connects to the new IP -CAN. The 
UE-1 obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over new IP-CAN 

The UE-1 registers with the S-CSCF over the new IP-CAN using the standard registration procedure. Depending 
on the UE-1 configuration, the discovery of the P-CSCF in the new IP-CAN can precede this. 

4. UE-1 acquires resources in new IP-CAN 

Based on the UE-1 and new IP -CAN capabilities, the UE-1 decides to use the same codec that was used over the 
old IP -CAN. The UE-1 reserves resources (e.g. QoS) in the new IP -CAN that will be needed for the signalling 
and transferred media, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.2-5 

The UE-1 sends initial SIP INVITE request with a new SDP offer to the UE-2 that indicates that the new call 
replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and specifies in the 
SDP the new contact address that will be used for media over the new IP-CAN. Upon sending the initial SIP 
INVITE request, the UE-1 is ready to receive the RTP packets either over the new IP-CAN or the old IP-CAN. 
The RTP packets can arrive over the new IP -CAN prior to the UE-1 receiving the SIP 200 (OK) response for the 
initial SIP INVITE request. 

Table A.7.2-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :pcscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> , <sip : origSscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net > 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=171828 

To: <tel : +l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree; replaces 

Replaces: me03a0s09a2sdf gj kl491777 ; to-tag=774321 ; f rom-tag=64727891 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
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Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "replaces" option tag indicate that the support for Replace header field is required. 
Replaces: specifies the existing call that will be replaced with the new call. 

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that the 
resources in the new IP -CAN have been acquired. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.7.2-7 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. In this example the 
SCC AS includes the contents of the Contact header field from the received SIP INVITE request. 

Table A.7.2-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .homel .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 67 

Route: <sip : sccas . homel . net ; lr> 

Record- Route : <sip:scscfl. homel . net ; lr> , <sip : pcscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net > , <tel : +l-212-555-llll> 
P -Access -Network- Info : Privacy : Require : replaces 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig- 
ioi=type3ashomel .net> 

P- Charging- Function- Addresses : ccf = [5555 : :b99 : c88 : d77 : e66] ; ccf = [5555 : : a55 : b44 : c33 : d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
From: <sip : userl_publicl@homel . net > ; tag=171828 
To: <tel : +l-212-555-2222> 
Call-ID: 
Cseq : 

Supported : 
Replaces : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c = 

t = 

m= 

b= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 



8. Remote leg update 

The SCC AS based on the content of the Replaces header field correlates the initial SIP INVITE request to the 
existing local and remote call legs of the existing concatenated end to end session between the UE-1 and UE-2. 
The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing the new 
SDP offer that it has received from the UE-1. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.2-9 
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The UE-2 is informed of the change in access leg by the SCC AS sending a SIP re-INVITE request to the S- 
CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE-1 (Step 5). 

Table A.7.2-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :user2_publicl@home2 . net ; gr=urn : uuid : 2ad8950e-4 8a5 -4a74 - 8d99-ad76cc7f c74 > SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route : <scscf 1 . homel . net ;lr>,<sip:scscf2. home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P- Asserted- Identity : P -Access -Network- Info : Privacy : P- Charging- Vector : icid- 

value="BzyretyU0dm+6O2IrT5tAFrbHLso=02 3 551034 11 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net > ; tag=1717777 
To: <tel : +l-212-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50 13333 
Cseq: 111 INVITE 
Supported : 

Contact : < sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- Ild0-a765- 
00a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: Accept: application/sdp 
Content-Type : 
Content-Length: (...) 

v=0 

= 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = - 

c= IN IP6 5555: : aaa: bbb: ccc : ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS:25.4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a= rtpmap:96 telephone-event 
a= maxptime:20 



Route: The SIP re-INVITE request contains the saved list of Route header fields that the SCC AS has saved for 
the remote leg of the call. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) - see example in table A.7.2-10 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 
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Table A.7.2-10: SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN 

subsystem entities) 



INVITE < sip :user2_publicl@home2 . net ; gr=urn : uuid : 2ad8 95 0e-4 8a5 -4a74 - 8d99-ad76cc7f c74 > SIP/2.0 
Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP sccas.homel.net; 

branch= z 9hG4bK3 3 2b3 3 . 3 ; 
Max-Forwards: 66 

Route : <sip:scscf2. home2 . net ; lr> , <sip :pcscf 2 . visited2 . net ; lr> 

P- Asserted- Identity : 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq : Supported : Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a76 5- 

0a0c91e6bf 6> ; +g . 3gpp . icsi-ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel 11 
Allow : 
Accept : 

Content-TypeContent-Length : 

v= 

o= 

s = - 

c= 

t= 

m= 

b= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 



11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards the UE-2 by the intermediate IM 
CN subsystem entities. 

12. Media paths between UE-1 and UE-2 

The UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that the UE-1 is ready to 
receive the same media on a different contact address. Since the UE-2 has resources already available, it starts to 
send the media to the UE-l's contact address specified in the SDP offer immediately. 

The UE-1 will be receiving the RTP packets over new IP-CAN. However, the UE-1 can receive some out-of- 
sequence RTP packets over the old IP -CAN. The RTP packets are delivered to the codec in sequence. Once the 
UE-1 determine that no media will be received over the old IP-CAN (e.g. by examining the sequence numbers in 
the RTP headers), it can relinquish the resources that it has been using for incoming media on the old IP -CAN. 

The UE-1 sends the media to the UE-2 over the old IP-CAN. 

Resources used for signalling on the old IP -CAN are not released. 

13. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-2 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 
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16. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

17. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

18. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the UE- 
2. 

19. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header field that was received in the initial SIP INVITE request 
(step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP 200 (OK) response to the 
initial SIP INVITE request contains the SDP answer that is identical to the SDP answer that the SCC AS has 
received in the SIP 200 (OK) response to SIP re-INVITE request from the UE-2 (Step 13). 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the UE-1. 

21. Media paths between UE-1 and UE-2 

The UE-1 receives the SIP 200 (OK) response containing the SDP answer that indicates that the UE-2 is ready to 
receive media. Since the UE-1 has already resources available, it starts to send media over new IP -CAN to the 
UE-2's contact address specified in the SDP answer immediately. 

The UE-1 can relinquish the resources that it has been using for outgoing media on the old IP-CAN. 
Resources used for signalling on the old IP -CAN are not released. 

22. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

The UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

23. SIP ACK request (-intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

24. SIP BYE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN, by sending a SIP BYE request to 
the UE-1. 

25. SIP BYE request (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP BYE request to the UE-1. 

26. SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the UE-1 sends a SIP 200 (OK) response over the old 
IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP -CAN. 

27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 
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A. 7. 3 PS-PS access transfer with partial media transfer 

The signalling flows shown in figure A.7.3-1 describes the PS-PS access transfer procedure when not all media of an 
ongoing communication session are transferred from the Source Access Leg to the Target Access Leg. No lower-level 
mechanism to support the access transfer is assumed or needed. 

In this example, UE-1 is on an active multimedia session with UE-2 via one IP-CAN. After connecting to an additional 
IP -CAN, obtaining an additional IP address, discovering a P-CSCF, and performing registration in the IM CN 
subsystem, UE-1 reserves resources in the new IP -CAN prior to initiating the PS-PS access transfer procedure. When 
the PS-PS access transfer procedure is completed, UE-1 continues the multimedia session with UE-2 on both the old 
and the new IP-CANs. In this example, when attaching to the new IP-CAN, it is irrelevant whether the UE-1 uses the 
same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that UE-1 and the IM CN subsystem support simultaneous multiple registrations 
and requires that UE-1 supports dual mode operation. 
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-Media Path over IP-CAN #2- 
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11. re-INVITE 



,12. 200OK(re-INV) 



17. ACK 



Figure A.7.3-1 : Signalling flow for PS-PS session transfer with partial media transfer 

NOTE 2: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

UE-1 is in an active session with UE-2. The call is anchored in the SCC AS. It is irrelevant which endpoint 
initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg over IP- 
CAN #1 is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=774321". UE-1 and UE-2 exchange media over the IP -CAN #1, which is maintained while the UE-1 initiates 
the session transfer procedure. 



2. UE-1 connects to IP-CAN #2 
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UE-1 connects to the new IP-CAN and obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over IP-CAN #2 

UE-1 registers with the S-CSCF over the IP -CAN #2 using the standard registration procedure. The P-CSCF in 
the signalling path of this registration can be distinct from the one used in the signalling path over IP-CAN #1. 

4. UE-1 acquires resources in IP-CAN #2 

UE-1 decides to perform partial media transfer to the IP-CAN #2. Based on UE-1 and IP -CAN #2 capabilities, 
the UE-1 decides to use the same codec that was used over the IP -CAN #1 for the media components to be 
transferred. UE-1 ensures that the resources (e.g. QoS) in IP -CAN #2 that will be needed for the signalling and 
transferred media are available, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-5 

UE-1 sends initial SIP INVITE request with a new SDP offer to UE-2 and indicates that the video component is 
to be transferred to IP -CAN #2. The initial SIP INVITE request establishes a dialog for signalling and specifies 
in the SDP new contact address that will be used for media over IP -CAN #2. Upon sending the initial SIP 
INVITE request, UE-1 is ready to receive the RTP packets over both IP -CAN #1 and IP-CAN #2. 

Table A.7.3-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp = sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net > 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 

To: <tel : +l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree; tdialog 

Target-Dialog: me03a0s09a2sdf gj kl491777 ; remote-tag=774321 ; local-tag=64727891 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : < sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a76 5- 

0a0c91e6bf G> ; +g . 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio RTP/AVP 97 96 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
m=video 34 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required. 
Target-Dialog: specifies the existing call that will be transferred. 
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SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that only the 
video component will be transferred and the resources in the new IP-CAN have been reserved. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. 

8. Remote leg update 

Based on the content of the Target-Dialog header field, the SCC AS correlates the SIP INVITE request for 
session transfer to the existing local and remote call legs of the existing concatenated end to end session between 
UE-1 and UE-2. The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the remote UE- 
2 containing the new SDP offer based on the partial media transfer request received from UE-1 and the 
negotiated SDP for the original session. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3-9 

UE-2 is informed of the change in access leg by the SCC AS sending a re-INVITE request to the S-CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is based on original SDP offer and the SDP offer that the SCC AS received in 
the initial SIP INVITE request from the UE-1 (Step 7). 
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Table A.7.3-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :User2_publicl@home2 . net ; gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 0> 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 70 

Route: <scscf 1 . homel . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net > , <tel : +l-212-555-llll> 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel : +l-212-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50 13333 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 

00a0c91e6bf 6> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

= 2987933100 2987933101 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = - 

t=o o 

m=audio 3456 RTP/AVP 97 96 

c = IN IP6 5555 :: aaa : bbb : ccc : eee 

b=AS : 25 . 4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode- change -period=2 

a= rtpmap:96 telephone -event 

a= maxptime:20 

m=video 3400 RTP/AVP 98 99 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 

b=AS : 75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Route: The SIP re-INVITE request contains the saved list of Route header fields that the SCC AS has saved for 
the remote leg of the call. 

SDP: specifies the new IP address and ports used for the media components. In this case, the audio component is 
still using the original address and port while the video component is using the new IP address and new port 
allocated. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 

11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards UE-2 by the intermediate IM CN 
subsystem entities. 

UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that UE-1 is ready to receive 
video media on a different contact address. Since UE-2 has resources already available, it starts to send the 
media to UE-l's contact address specified in the SDP offer immediately. 

UE-1 starts receiving the video RTP packets over IP -CAN #2. However, UE-1 can receive some out-of-sequence 
video RTP packets over IP -CAN #1. The video RTP packets are delivered to the codec in sequence. Once UE-1 



ETSI 



3GPP TS 24.237 version 9.2.0 Release 9 



100 



ETSI TS 124 237 V9.2.0 (2010-04) 



determine that no video will be received over IP-CAN #1 (e.g. by examining the sequence numbers in the RTP 
headers), it can relinquish the resources that it has been using for incoming video media on IP-CAN #1 . 

At the same time, UE-1 still sends both the audio and video media to UE-2 over IP -CAN #1. 

Resources used for signalling on IP -CAN #1 are not released. 

12. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) - see example in table A.7.3-12 

Upon receiving the SIP re-INVITE request containing the SDP offer, since UE-2 has all resources available, it 
sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

Table A.7.3-12: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via : SIP/2 . 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , 

SIP/2 . 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , 

SIP/2 . 0/UDP scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1 , 

SIP/2 . 0/UDP sccas .homel .net ;branch=z9hG4bK332b33 . 3 
Record- Route : <sip : pcscf 2 . visited2 . net : 50 88 ; lr ; comp=sigcomp> , <sip:scscf2. home2 . net ; lr> , 

<sip:scscfl .homel .net ; lr> 
P- Access -Network- Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel : +1-212 -555 -2222 >;tag=4321 

Call- ID: dcl4bltl0b3teghmlk5 013333 

CSeq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip :user2_publicl@home2 . net ; gr=urn :uuid : 2ad8950e-4 8a5-4a74 - 8d99- 

ad76cc7f c74> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933624 IN IP6 5555 : : eee : f f f : aaa : bbb 
s = - 

c=IN IP6 5555: :eee:fff : aaa : bbb 
t = 

m=audio 6544 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=video 10001 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 



13. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 

15. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 
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The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re -INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

16. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

17. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to UE-2. 

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
18 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header field that was received in the initial SIP INVITE request 
(step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) 
response to the initial SIP INVITE request contains the SDP answer derived from the SDP answer that the SCC 
AS has received in the SIP 200 (OK) response to SIP re-INVITE request from UE-2 (Step 14). 

Table A.7.3-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , 
SIP/2 . 0/UDP pesef 1 .homel .net ;branch=z9hG4bK24 0f 34 . 1 , 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : <sip : sccas . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> , <sip :pcscf 1 . homel . net ; lr> 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=171828 
To: <tel : +1-212- 555-2222 >;tag=800 9 
Call- ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : < sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 

ad76cc7f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: eee : fff : aaa :bbb 
s = - 

c=IN IP6 5555 :: eee : fff : aaa :bbb 
t = 

m=audio RTP/AVP 97 96 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
m=video 10001 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 



19. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 
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UE-1 receives the SIP 200 (OK) response containing the SDP answer indicating that UE-2 is ready to receive 
media. Since UE-1 has already resources available, it starts to send video media over IP-CAN #2 to UE-2's 
contact address specified in the SDP answer immediately. 

The UE-1 can relinquish the resources that it has been using for outgoing video media on IP-CAN #1. 
Resources used for signalling and audio media on IP-CAN #1 are not released. 

20. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

21. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

22. SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-22 

UE-1 updates the old call leg on IP-CAN #1 by sending a SIP re-INVITE request to the intermediate IM CN 
subsystem entities. 

Table A.7.3-22: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip :User2_publicl@home2 . net ; gr=urn : uuid : 2ad8 950e-4 8a5 -4a74 - 8d99-ad76cc7f c74 > SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : eee] : 2468 ; comp=sigcomp ;branch=z9hG4bKashdnsl 
Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 8765 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P- Access -Network- Info : 3GPP-UTRAN-FDD; utran-cell-id-3gpp=12 34 5 6ABCDE22 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=64727891 
To: <tel : +l-212-555-2222>; tag=774321 
Call -ID: me 3a0s0 9a2sdfgjkl4 91777 
Cseq: 101 INVITE 

Supported: lOOrel; precondition; tdialog 
Require: sec-agree; 
Proxy-Require : sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=12345678 ; portl=2468 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf 6> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933000 2987933001 IN IP6 5555 :: aaa :bbb : ccc : eee 
s = - 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS. 

24. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
24 

The SCC AS updates the old call leg based on the SIP re-INVITE request and sends the SIP 200 (OK) response 
to the SIP re-INVITE request to the intermediate IM CN subsystem entities, using the content of the Via header 
field that was received in the SIP re-INVITE request (step 23). In this example the SCC AS includes the contents 
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of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) response to the SIP re- 
INVITE request contains the SDP answer derived from the SDP answer that the SCC AS previously received 
from UE-2 (Step 14). 

Table A.7.3-24: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK345b32 . 2 , 
SIP/2 . 0/UDP pcscfl .homel .net ;branch=z9hG4bK56 8f 3 5 . 1 , 

SIP/2 . 0/UDP [5555 : : aaa : bbb : ccc : eee] : 2468 ; comp=sigcomp;branch=z9hG4bKashdnsl 
Record-Route : <sccas . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> , <sip :pcscf 1 . homel . net ; lr> 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=64727891 
To: <tel : +1-212 -555 -2222 >;tag=774321 
Call -ID : me03a0s09a2sdfgjkl4 91777 
Cseq: 101 INVITE 

Supported: lOOrel; precondition 

Contact : < sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 

ad7 6 cc 7 f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933800 2987933801 IN IP6 5555 :: eee : fff : aaa : bbb 
s = - 

c = IN IP6 5555: :eee:fff : aaa : bbb 

t=o o 

m=audio 6544 RTP/AVP 97 96 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



25. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 

26. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the old call leg update with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

27. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 



A.8 Signalling flows for PS-PS access transfer in 
conjunction with PS-CS access transfer 

A.8.1 Introduction 

The signalling flows for PS-PS access transfer conjunction with PS-CS access transfer demonstrate how a multimedia 
session is tranferred from Source Access Leg to the Target Access Leg. The following signalling flows are included: 

subclause A. 8. 2 shows an example when a multimedia session is transferred from one IP-CAN to a new IP -CAN 
and the CS bearer respectively ; and 

- subclause A. 8. 3 shows an example when a multimedia session is transferred from one IP -CAN and CS bearer to 
a new IP -CAN. 
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A.8.2 PS - PS in conjunction with PS - CS Access Transfer: PS to 
CS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 before access transfer. 
When SC UE connects to a new IP-CAN#2, it decides to transfer the multimedia session over the new IP-CAN#2 and 
the CS bearer respectively. 
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Figure A.8.2-1 : Signalling flow for PS - PS in conjunction with PS - CS Access 

Transfer: PS to CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over 
old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=774321". The UE A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE 
A initiates the handover procedure. 

Table A.8.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 

NOTE 2: To later show how the media is transferred to the new IP -CAN and CS bearer, only the SDP offer is 
shown in table A.8.2-1. 

Table A.8.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-2222 SIP/2.0 
Via: 

Max- Forwards : 
Route : 

P- Asserted- Identity : 

P-Charging-Vector : 

P-Access-Network-Info : 

Privacy : 

From: 

To: 

Call-ID: 
Cseq : 

Supported : 
Require : 
Proxy-Require : 
Security-Verif y : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
a=accept-types : text/plain 



2. SC UE A connects to a new IP-CAN#2: 

The SC UE A decides to transfer the multimedia session over the new IP -CAN and CS bearer respectively. The 
UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the 
new IP -CAN using multiple registrations procedure. Depending on the UE A configuration, the discovery of the 
P-CSCF in the new IP-CAN can be needed. Based on the UE A and new IP -CAN capabilities, the UE A decides 
to use the same codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new 
IP-CAN that will be needed for the signalling and transferred media, prior to sending the initial SIP INVITE 
request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.2-3 
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The SC UE A sends an initial SIP INVITE request with a STI and a new SDP offer to the UE B that indicates 
that the new call replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and 
specifies in the SDP a new contact address that will be used for non-realtime media over the new IP -CAN. Upon 
sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new IP- 
CAN or the old IP -CAN. The RTP packets can arrive over the new IP-CAN prior to the SC UE are receiving the 
SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip :userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Target -Dialog :me03a0s09a2sdfgjkl4 91777; to-tag=774 321 ; f rom-tag=64 72 78 91 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : fff 
s = 

t = 

m=audio RTP/AVP 97 96 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 

c = IN IP6 5555: : aaa : bbb : ccc : fff 

a=accept-types : text/plain 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.2-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
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request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :user2_publicl@home2 . net ; gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74>; SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; lr > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> , <tel : +l-237-555-llll> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel : +l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk5 0132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : < sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 

00a0c91e6bf 6> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 
s=t=0 

m=audio RTP/AVP 97 96 

c = IN IP6 5555: : aaa: bbb: ccc : ddd 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 

c = IN IP6 5555: : aaa : bbb : ccc : f f f 

a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The non-realtime media is using the new IP -CAN while the realtime media path is still over the old IP-CAN. 

18. CC SETUP message (SC UE A to Interworking entities) 

The SC UE sends the CC SETUP message with the STN as the called party number. 
NOTE 3: STN is a PSI DN used by the UE to request a session transfer towards the SCC AS. 
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19. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
Table A.8.2-19 

Table A.8.2-19: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.homel.net; branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : icscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel: +1-23 7- 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj4903 3 3 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 

Contact : <sip : mgcf 2 . home2 . net ; gr> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept: application/sdp , application/3gpp- ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 



v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

20. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

21. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

22. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

23. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.8.2- 
23 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header 
field from the received SIP INVITE request. 
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Table A.8.2-23: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :user2_publicl@home2 . net ;gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf = [5555 : : b99 : c88 : d77 : e66] ; ccf = [5555 : :a55 :b44 : c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- 

ioi= " type3homel . net " 
Privacy: none 

From: <tel: +1-23 7- 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-2222>; tag=26545 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 
Contact : < sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 
00a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

t = 

m=audio 3456 RTP/AVP 97 96 
c=IN IP6 5555 :: aaa :bbb : ccc : eee 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 

c = IN IP6 5555: : aaa : bbb : ccc : f f f 

a=accept-types : text/plain 



24. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

25. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

26. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

27-28. SIP ACK request (SCC AS to UE B via EVI CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

29-30. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

31. CC CONNECT message (interworking entities to SC UE A) 
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32. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to interworking entities) 

33-34. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

35-36: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a BYE request to the 
UE A. 

37-38. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE SIP request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

39. Media paths between SC UE A and UE B 

Finally, the non-realtime media path is over the new IP -CAN and the realtime media is using the CS bearer. 

A.8.3 PS - PS in conjunction with PS - CS Access Transfer: CS to 
PS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 and CS bearer before 
access transfer. When SC UE connects to a new IP-CAN#2, it decides to transfer all the multimedia session over the 
new IP-CAN#2. 
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l . SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 



-1 a.non-realtime media path over IP-CAN# 1 ■ 
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2. UE A connects to a new IP-CAN 
and decides to transfer the multimedia 
session over the new IP-CAN . It 
reserves resources in the new IP-CAN. 
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Figure A.8.3-1 : Signalling flow for PS - PS in conjunction with PS - CS Access 
Transfer: CS to PS 



NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
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1. SC UE A has an ongoing multimedia session with remote UE B 

The non realmedia path is over old IP-CAN#1 and the realtime media path is over the CS bearer. The call has 
been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over old IP-CAN#1 
is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321". The UE 
A and UE B exchange media over the old IP -CAN, which is maintained while the SC UE A initiates the 
handover procedure. 

2. SC UE A connects to a new IP-CAN#2 

The SC UE A decides to transfer the multimedia session over the new IP-CAN#2. The UE A obtains an IP 
address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using 
multiple registrations procedure. Depending on the UE A configuration, the discovery of the P-CSCF in the new 
IP-CAN can precede this. Based on the UE A and new IP -CAN capabilities, the UE A decides to use the same 
codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new IP-CAN that will 
be needed for the signalling and transferred media, prior to sending the initial SIP INVITE request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.3-3 

Upon sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new 
IP-CAN or the old IP-CAN. The RTP packets can arrive over the new IP-CAN prior to the SC UE are receiving 
the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.3-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID : Cb03a0s09a2sdfglkj49023 7 

Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr= urn : uuid :f81d4fae-7dec-lld0-a765- 

00a0c91e6bf G> ; +g . 3gpp . icsi -ref = "urn%3Aurn-xxx%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Replaces: me03a0s09a2sdf gj kl491777 ; to-tag=774321 ; f rom-tag=64727891 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : fff 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : fff 

t = 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
a=accept-types : text/plain 



Request-URI: Contains the static STI. 
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4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STL The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.3-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip : user2_publicl@home2 . net ; gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; lr > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> , <tel : +l-237-555-llll> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=569812 
To: <tel : +l-237-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk5 0132 3 7 
Cseq: 111 INVITE 

Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91eGbf G> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 

s = 

c = IN IP6 5555: : aaa : bbb : ccc : f f f 

t = 

m=audio 3456 RTP/AVPF 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 
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The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The multimedia is using the new IP -CAN. Resources used for signalling on the old IP-CAN#1 and CS bearer are 
not released. 

18-19. SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN#1, by sending a SIP BYE request 
towards the SC UE A. 

20-21. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN#1, the SC UE A sends a SIP 200 (OK) response over 
the old IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN. 

22-23. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

24-25. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 

26-27. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 
28. Media paths between UE A and UE B 

The multimedia session is using the new IP-CAN#2. 

A.9 Signalling flows for media adding/deleting for access 
transfer 

A.9.1 Introduction 

The signalling flows for media adding/deleting demonstrate how the media of a multimedia session is added or deleted. 
The following signalling flow is included: 

- subclause A. 9. 2 shows an example when the non-realtime media of a multimedia session over the IP -CAN is 
removed. 

A. 9. 2 Remote End Initiation case - Removing media from split CS 
and PS sessions 

As a precondition the SC UE A has a CS call and IMS multimedia session with the remote UE after session transfer in a 
manner that more than one session are presented to UE B as one IMS session by the SCC AS. 
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SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 



• la.CS bearer--- 



■la.realtime media path- 



■lb.non-realtime media path- 



-9. SIP BYE- 



-10. SIP 200 (OK>- 



•12.CS bearer- • 



-2. SIP relNVITE 



-3. SIP relNVITE* 

4. SIP 200 (OK) 



relNVITE 



5 SIP 

200 (OK) relNVITE 
I 



-6. SIP ACK- 



-7 SIP ACK- 
-8. SIP BYE- 



-11. SIP 200 (OK>- 
■12. realtime media path — 



Figure A.9.2-1 : Remote End Initiation case - Removing media from split CS and PS 

sessions 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 
Table A.9.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 
NOTE 2: To show how the media is removed, only the SDP offer is shown in this example. 
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Table A.9.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-2222 SIP/2.0 
Via : 

Max- Forwards : 
Route : 

P- Asserted- Identity: 
P- Charging- Vector : 
P-Access-Network-Info : 
Privacy : 
From: 
To : 

Call-ID: 
Cseq : 

Supported : 
Require : 
Proxy-Require : 
Security-Verify : 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : ddd 
t = 

m=message 7654 TCP/MSRP 98 
a=accept-types : text/plain 



2. SIP re-INVITE request (UE B to intermediate IM CN subsystem entities)- See example in table A.9.2.-2 

The remote UE B decides to remove the non-realtime media from the multimedia session. It uses standard IMS 
procedures to remove one or more PS media from the session. 
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Table A.9.2-2: SIP re-INVITE request (UE B to intermediate IM CN subsystem entities) 



INVITE < sip :userl_publicl@homel . net ;gr=urn :uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-2222> 

P- Charging- Function- Addresses : ccf=[5555::b9 9:c88:d7 7:e66]; ccf = [5555 : :a55 :b44 : c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- 

ioi= " type3homel . net " 
P-Access-Network-Info : 
Privacy: none 

From: <tel: +1-237-555-2222; gr=hdg7777ad7af lzig8sf 7> ; tag=171828 

To: <tel : +l-237-555-llll> 

Call -ID : Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 
Contact : < sip :user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 

ad76cc7f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
m=message TCP/MSRP 98 
a=accept-types : text/plain 



3. SIP re-INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

4-5. SIP 200 (OK) response (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the remote 
UEB. 

6-7: SIP ACK request (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP ACK request to the SIP SIP 200 (OK) response and forwards it to the SCC AS. 

8-9: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the IP -CAN, by sending a SIP BYE request to the 
UE A. 

10-11. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the IP-CAN, the SC UE A sends a SIP 200 (OK) response over the IP- 
CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the IP-CAN. 

12. Media paths between SC UE A and UE B 

Finally, the non-realtime media path over the IP-CAN is removed. 
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A.1 Signalling flows for Inter-UE Transfer without 
establishment of Collaborative Session 

A.1 0.1 Introduction 

The signalling flows in the subclause demonstrate how a UE-1 can initiate the inter UE transfer of the complete session 
without Collaborative Session establishment. 

The example assumes that the UE-1 and UE-2 are under the control of the same subscriber. 

A.1 0.2 Complete transfer in services defining only originating 
session set up in UE 

In the example flow at the figure A. 10.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS. 
The session is established using an IMS communication service identified by ICSI urn:urn-7:3gpp-service.ims.icsi.iptv 
which is an IMS communication service which defines originating session set up in the UE only. 
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Figure A.10.2-1 : Signalling flow for inter UE transfer without Collaborative Session 

establishment 

NOTE 1: For clarity, the SIP 100 (Trying) responses and the SIP NOTIFY requests earring the message/sipfrag 
with SIP 100 (Trying) response are not shown in the signalling flow. 



1. UE-1 is in session with UE-3 
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There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 
anchored at SCC AS. The session was established using IMS communication service identified by ICSI urn:urn- 
7:3gpp-service.ims.icsi.iptv. The dialog identifier of the session is AB03a0s09a2sdfglkj490333, remote- 
tag=Afgsdfg45, local-tag=U188gg. 

2. SIP REFER request initiating the inter UE transfer to UE-2 (UE-1 to Intermediate IM CN subsystem 
entities) - see example in table A. 10.2-2 

Table A.10.2-2: SIP REFER request (UE-1 to Intermediate IM CN subsystem entities) 



REFER sip :user@homel . net ; gr=urn : uuid : f 8 ld4f ae-7dec- Ild0-a76 5 -222222222222 SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P- Preferred- Identity : <sip : userohomel . net > 
From: <sip :user@homel . net> ; tag=171828 

To: < sip : userohomel . net ; gr=urn : uuid : f 8 ld4fae-7dec -Ild0-a76 5 -222222222222 > 
Call-ID: Asdasd231233 
Cseq: 4127 REFER 

Contact : <sip : userohomel . net ; gr=gr=urn : uuid : f 8 ld4fae- 7dec- lldO -a76 5- 111111111111 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Length: 

Refer-To : <sip : interUEtransf erOsccas . homel . net?Target- 

Dialog=AB03a0s09a2sdfglkj490333%3Bremote-tag=Afgsdfg45%3Blocal- 

tag=U188gg&Require=tdialog&P-Pref erred-Service=urn : urn- 7 : 3gpp-service . ims . icsi . iptv&Accept- 
Contact=*%3b+g . 3gpp . icsi-ref %3d%2 2urn%2 53Aurn-7%2 53gpp-service . ims . icsi . iptv%2 2> 



Request-URI: contains the GRUU of the UE-2 

Refer-To: contains the Inter UE Transfer SCC AS URItogether with Target-Dialog URI header field 
containing the dialog identifier of the session with UE-3, Require URI header field containing the "tdialog" and 
P-Preferred-Service and Accept-Contact URI header fields containing the ICSI of the service to be requested by 
UE-2. 

Contact: contains the GRUU of the UE-1 

3. Evaluation of initial filter criteria 

The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP REFER 
request towards the SCC AS. 

4. SIP REFER request (Intermediate IM CN subsystem entities to SCC AS) 

5. The SCC AS authorizes the request and if authorization is passed successfully, the SCC AS forwards the 
SIP REFER request further 

6. -7. SIP REFER request (SCC AS to UE-2) 

8.-11. SIP 202 (Accepted) response to the SIP REFER request (UE-2 to UE-1) 

12. SIP INVITE request (UE-2 to intermediate IM CN subsystem entities) - see example in table A.10.2-12 
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Table A.10.2-12: SIP INVITE request (UE-1 to Intermediate IM CN subsystem entities) 



INVITE sip : interUEtransf erOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : f f f ] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P- Preferred- Identity : <sip : userohomel . net > 

From: <sip :user©homel . net> ; tag=171828 

To : <sip : interUEtransf erOsccas . homel . net> 

Call-ID: tq34gasgaegr 

Cseq: 4127 INVITE 

Contact : <sip : userohomel . net ;gr=urn : uuid : f 8 ld4fae-7dec- Ild0-a76 5 -222222222222 > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Target -Dialog: AB03a0s09a2sdf glkj 4 90333 ; remote- tag=Afgsdfg4 5 ; local -tag=U18 8gg 

Require : tdialog 

Content-Type: application/sdp 

Content-Length: (...) 

Supported: lOOrel, precondition 

P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . iptv 

Accept -Contact : * ; +g . 3gpp . icsi -ref ="urn%3Aurn-7%3gpp- service . ims . icsi . iptv" 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : fff 
s = 

c=IN IP6 5555 :: aaa :bbb : ccc : fff 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=video 3400 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: set to the URI in the Refer-To of the received SIP REFER request 
Contact: contains the GRUU of the UE-2 

Target-Dialog: set to the value of the Target-Dialog URI header field of the URI in the Refer-To of the 
received SIP REFER request 

Require: set to the value of the Require URI header field of the URI in the Refer-To of the received SIP 
REFER request 

P-Preferred-Service: set to the value of the P-Preferred-Service URI header field of the URI in the Refer-To 
of the received SIP REFER request 

Accept-Contact: set to the value of the Accept-Contact URI header field of the URI in the Refer-To of the 
received SIP REFER request 

13. Evaluation of initial filter criteria 

The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP INVITE 
request towards the SCC AS. 

14. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

15. Remote Leg Update 



ETSI 



3GPP TS 24.237 version 9.2.0 Release 9 



123 



ETSI TS 124 237 V9.2.0 (2010-04) 



Based on the STI in the Target-Dialog header field the SCC AS detects that the inter UE tranfer is being 
attempted and performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

16-18. SIP re-INVITE request (SCC AS to UE-3 over intermediate EVI CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP 
INVITE request and the information previously stored against this session and routes it towards UE-3 via the 
intermediate IM CN subsystem entities. 

19-21. SIP 200 (OK) response (UE-3 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-3 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

22-24. SIP ACK request (SCC AS to UE-3 via intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE-3. 

25-26. SIP 200 (OK) response (SCC AS to UE-2 via intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the UE-2. 

27-28. SIP ACK request (UE-2 to SCC AS via intermediate IM CN subsystem entities) 

The UE-2 generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC AS. 

29. Media and IMS service control paths: 

The media path is now established between UE-2 and UE-3 and the IMS service control between UE-2 and SCC 
AS. 

30-33. SIP NOTIFY request (UE-2 to UE-1 over intermediate IM CN subsystem entities and SCC AS) 

The UE-2 generate the SIP NOTIFY request carrying the message/sipfrag body and send it towards UE-1. 

34-37. SIP 200 OK response to the SIP NOTIFY request (UE-1 to UE-2 over intermediate IM CN subsystem 
entities and SCC AS) 

38-39: SIP BYE request (SCC AS to UE-1 via intermediate IM CN subsystem entities) 

The SCC AS terminates the source access leg by sending a BYE request to the UE-1. 

40-41. SIP 200 (OK) response (UE-1 to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request, the UE-1 sends a SIP 200 (OK) response to the SCC AS. Subsequently, 
the UE-1 relinquishes all resources pertaining to the session. 

A. 10.3 Complete transfer in services defining terminating session 
set up in UE 

Editor's note: Complete transfer in services defining terminating session set up in UE is FFS 
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A.1 1 Signalling flows for establishment of collaborative 
session for inter-UE transfer 

A.1 1.1 Introduction 

The signalling flows for establishing a collaborative session. Two different scenarios have been considered in the 
clause: 

- the first scenario is when the collaborative session established by transferring media component from controller 
UE to a controllee UE. This scenario is similar to the procedures described in subclause A. 13.2 with exception 
that upon receipt of SIP REFER request from the controller UE, the SCC AS generates a SIP INVITE request 
instead of a SIP re-INVITE request and send it to the controllee UE; and 

- the second scenario is described in subclause A. 1 1 .2 and shows an example where the collaborative session 
established by adding a new media component on a controllee UE. 

A.1 1 .2 Collaborative session establishment with new media 

There is an existing session with audio between controller UE, UE-1, and remote UE. The controller UE establishes a 
collaborative session by adding a video media component to the controllee UE, UE-2. 
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Figure A.11.2: Controller UE establishes a collaborative session by adding a new 

media on controllee UE 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1-2. SIP REFER request (from UE-1 to SCC-AS) 

The controller UE, UE-1 sends a SIP REFER request to the SCC AS containing a Refer-To header field 
containing the GRUU of controllee UE, UE-2 and a body parameter containing an m line for audio set to zero 
and an m line for video with the port number set to the discard port number "9" since the port number is 
unknown. The SIP REFER request also includes a Target-dialog header field containing the details fo the dialog 
for the existing session between controller UE, UE-1 and the remote UE. 
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Table A.1 1.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 




Via : 




To : sip : interUEtransf erSsccasl . homel . net 




From: sip:userl publiclohomel . net ; tag=2468 




Call -ID: Cb03a0s09a2sdfglkj4 90333 




CSeq: 93809824 REFER 




Max-Forwards: 70 




P -Preferred- Identity : 




Refer-To: <sip:userl public2@home2 . net ; gr=urn :uuid 


f 81d4f ae-7dec-lld0-a762- 


00a0c91e6bf e?body=m%3Daudio%2 00%2 0RTP%2FAVP%2 096%0Dm%3Dvideo%2 09%2 0RTP%2FAVP%2 098%2 099> 


Require: target-dialog 




Target-dialog: cb03a0s09a2sdf glkj 13579 ; remote-tag= 


abcdef; local-tag=123456 


Contact: <sip : userl_publicl@homel . net ; gr=urn:uuid 


f 81d4fae-7dec-lld0-a765- 


0a0c91ewxyz> ; +g . 3gpp . iut -controller 




Allow : 




Accept: message/sipf rag 




Content-Length: 





3-4. SIP 202 (Accepted) response (from SCC AS to UE-1) 

SCC-AS sends SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 
5-6. SIP NOTIFY request (from SCC AS to UE-1) 

SCC-AS sends a SIP NOTIFY request to UE-1 notifying implicit subscription to the SIP REFER request. 

Table A.1 1.2-2 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via: 

To : sip :userl_publicl@homel . net ; tag=24680 

From : sip : interUEtransf erOsccasl . homel . net ; tag=13 579 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active; expires=36 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC- 
AS. 

9-10. SIP INVITE request (from SCC-AS to UE-2) 

SCC-AS sends SIP INVITE request to the controllee UE, UE-2, adding video media and establishing 
collaborative session. Since the URI parameters indicates that the port number for video m-line is set to the 
discard port number "9", the SCC AS realizes that the port number of the remote UE is unknown and therefore 
adds an a-line to inactive in SDP offer to prevent the controllee UE sending media to the remote UE. The SDP 
offer contains the audio media component on controller UE, UE-1 set to zero. The SIP INVITE request contains 
a Referred-By header field containing the identity of UE-1. 
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Table A.1 1.2-3 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip :user2_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

Record-Route : sip : scc-as@homel .net 

To : sip : user2_publicl@homel . net ; 

From : sip : user3_public3@home3 . net ; tag=acegi 

Call-ID: 

CSeq: 

Max- Forwards : 

P-Asserted- Identity : "remote user" sip : user3_public3@home3 . net 
Require : 

Ref erred-By : sip : userl_publicl@homel . net 

Contact : sip : user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae- 17oct- llal-a678 - 0054c91eabcd 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio RTP/AVP 
m=video 9 RTP/AVP 98 99 
a=inactive 
c=123 . 112 .67.87 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Editor's note: The value of c-line is FFS. 

11-12. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending SIP 200 (OK) reqponse to SCC- 
AS. 

Table A.1 1.2-11 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 
Via : 

To : sip : user2_publicl@homel . net ; tag=xyzwv 
From : sip : user3_public3@home3 . net ; tag=acegi 
Call-ID: 
CSeq: 

P -Preferred- Identity : 

Contact : sip : userl_public2@home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 

0a0c91e6bf 6+g . 3gpp . iut- controller 
Allow: INVITE, PRACK, UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 
s = - 
t = 

m=audio RTP/AVP 
m=video 9 RTP/AVP 98 
a=inactive 
c=145 .23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



13-14. SIP ACK request (from SCC-AS to controllee UE) 

SCC-AS sends SIP ACK request to the remote UE. 
15-16. SIP re-INVITE request (from SCC-AS to remote UE) 

SCC-AS sends SIP re-INVITE request to the remote UE. 
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Table A.11.2-15 SIP re-INVITE request (SCC-AS to remote UE) 



INVITE sip :user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae-17oct-llal-a678-0054c91eabcd SIP/2 . 
Via : 

To : sip : user3_public3@home3 . net ; tag=66666 
From: sip : userl_publicl@homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 
t = 

m=audio 1300 RTP/AVP 96 97 
c=IN IP4 123 .45.67.89 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 2 

m=video 13 02 RTP/AVP 98 

C=IN IP4 145 .23.77.88 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



17-18. SIP 200 (OK) response (from remote UE to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending SIP 200 (OK) response to the SCC-AS. 



Table A.11.2-17 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To : 




From : 




Call-ID: 




CSeq: 




P- Asserted- Identity : 




Contact: sip:user3 public3@home3 


net ;gr=urn: uuid : f 81d4f ae- 17oct- llal-a678 - 054c91eabcd 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123 . 112 .67.87 


s = - 

c=IN IP4 123.112.67.87 




t = 




m=audio 3 000 RTP/AVP 96 97 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode 


-change -per iod=2 


a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=video 3 02 RTP/AVP 98 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 





19-20. SIP ACK request (from SCC-AS to remote UE) 

SCC-AS sends SIP ACK request to the remote UE. 
21-22. SIP re-INVITE request (from SCC-AS to UE-2) 
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The SCC-AS sends a SIP re-INVITE request to the controllee UE, UE-2 to inform controllee UE about the port 
number for the video media component of the remote UE. The SCC AS add an a-line set to active in the SDP 
offer. 

NOTE 1: This SIP re-INVITE request is triggered by the SIP REFER request in steps 1-2. The previous SIP 

INVITE request was generated by the SCC AS due to third party call control to allow sending this SIP re- 
INVITE request. 

NOTE 2: Any other changes such as IP address of the remote UE in case remote UE uses different IP addresses for 
different media would also be updated in the SIP re-INVITE request. 

Table A.1 1.2-21 SIP re-INVITE request (SCC-AS to UE-2) 



INVITE sip : userl_public2@home2 . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 

Via : 

To: 

From: 

Call-ID: 

CSeq: 

Contact : sip : user3_public3@home3 . net ;gr=urn : uuid : f 81d4f ae-17oct-llal-a678-0054c91eabcd 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.87 
s = - 

C=IN IP4 123.45.67.87 
t = 

m=audio RTP/AVP 96 97 

m=video 3 02 RTP/AVP 98 

b=AS : 75 

a=active 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



23-24. SIP 200 (OK) response (from controllee UE to SCC-AS) 

Table A.1 1.2-23 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

Contact : sip : userl_public2@home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 00a0c91e6bf 6 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 
s = - 
t = 

m=audio RTP/AVP 

m=video 13 02 RTP/AVP 98 

c=145 .23 . 77 . 88 

b=AS : 75 

a=active 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



25-26. SIP ACK request (from SCC-AS to controllee UE) 

SCC-AS sends SIP ACK request to controllee UE to acknowledge. 
27-28. SIP NOTIFY request (from SCC-AS to conroller UE, UE-1) 
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When the media component is added to the controllee UE, UE-2, the SCC-AS sends SIP NOTIFY request to 
controller UE, UE-1 to inform about the success status of adding the media to the UE-2. 

Table A.1 1.2-27 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via: 

To: sip : userl_publicl@homel . net ; tag = 13579 
From: sip : scc-as@homel . net ; tag=2468 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow : 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

m=audio RTP/AVP 

m=video 1302 RTP/AVP 98 99 

c=145 .23.77.88 

b=AS : 75 

a=active 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



29-30. SIP 200 (OK) response (from controller UE to SCC-AS) 

The controller UE acknowledges the NOTIFY request by sending SIP 200 (OK) response to SCC-AS. 



A.1 2 Signalling flows for media transfer within 
collaborative session for inter-UE transfer 

A.1 2.1 Introduction 

This subclause describes signalling flows for media transfer within collaborative session. Two different scenarios are 
considered in the clause: 

- subclause A. 12.2 shows an example where media component is transferred from controller UE to controllee UE; 
and 

- subclause A. 12.3 shows an example where media component is transferred from one controllee UE to another 
controllee UE. 
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A. 12.2 Controller UE initiated media transfer from controller UE to 
controllee UE 



UE-1 



UE-2 



IMS CN 



SCC AS 



Remote 
UE 



-(Audio, Video)- 



-1. REFER- 



-4. 202 ACCEPTED- 

6. NOTIFY 

—7. 200 OK— 



-10. INVITE- 



-11.200 OK- 



-20. ACK- 



-22. Re-INVITE- 
— 23. 200 OK— 
—26. ACK — 



-28. NOTIFY- 



-29. 200 OK- 



-2. REFER- 



I-3. 202 accepte: 
I 5. NOTIFY — 

—8. 200 OK— 
I 9. INVITE 



-12. 200 OK- 



-13. Re-INVITE- 



-14. Re-INVITE- 
— 15. 200 OK— 



-16.200 OK- 
— 17. ACK— 



-19. ACK- 



-21. Re-INVITE- 
— 24. 200 OK— 

—25. ACK— 



-27. NOTIFY- 



-30. 200 OK- 



■(Audio). 



18. ACK- 



-(Video)- 



Figure A.12.2: Controller UE transfers a media on controllee UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1-2. SIP REFER request (SIP REFER request from UE-1 to SCC-AS) 

There is an existing session with audio and video between controller UE, UE-1 (123.45.67.89), and remote UE 
(132.54.76.98). The video component is unidirectional from the remote UE to the controller UE, UE1. The 
Controller UE attempts to transfer the video portion of this session to the controllee UE, UE-2. 
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Table A.1 2.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 
Via : 

To : sip : interUEtransf er@sccasl . homel . net 

From: sip : userl_publicl@homel . net ; tag=13579 

Call -ID: Cb0 3a0s09a2sdfglkj 490333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Refer- To : <sip : userl_public2@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 ?body= 

m%3Daudio%2 00%2 0RTP%2FAVP%97%0Dm%3Dvideo%203 002%2 0RTP%2FAVP%2 098%2 099> 
Require: target-dialog 

Target -dialog: cb0 3a0s0 9a2sdf glkj 321576 ; remote- tag=abcdef ; local -tag=1234 56 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

00a0c91ewxyz> ; +g . 3gpp . iut-controller 
Accept: application/sdp, message/sipf rag 
Content-Length: 



3-4. SIP 202 (Accepted) response (from SCC AS to UE-1) 

SCC-AS sends SIP 202 (Accepted) response to controller UE-1 as response to SIP REFER request. 
5-6. SIP NOTIFY request (from SCC AS to UE-1) 

SCC-AS sends SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request results. 

Table A.1 2.2-2 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip :userl_publicl@homel .net ;gr=urn: uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via : 

To : sip : userl_publicl@homel . net ; tag=24680 

From : sip : interUEtransf er@sccasl . homel . net ; tag=13 579 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow : 

Event : refer 

Subscript ion- St ate : active ; expires=3600 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC- 
AS. 

9-10. SIP INVITE request (from SCC-AS to UE-2) 

SCC-AS sends SIP INVITE request to the controllee UE, UE-2, to transfer video media. 

Editor" s Note: It is ffs how the controller UE signals what media are to be transferred when the SDP media order 
is different in controller UE and controllee UE. 
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Table A.1 2.2-3 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip :userl_public2@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To : sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio RTP/AVP 97 
m=video 3002 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



11-12. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending SIP 200 (OK) response to SCC-AS. 



Table A.12.2-4 SIP 200 OK response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sip:userl public2@homel.net; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag = 


= 12486 


Call-ID: 




CSeq: 




P -Preferred- Identity : 




Contact: sip:userl public2@homel 


net ;gr=urn: uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow : 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


145 .23.77.88 


s = - 

c=145 .23.77.88 




t = 




m=audio RTP/AVP 97 




m=video 1302 RTP/AVP 98 99 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 





13-14. SIP re-INVITE request (from SCC-AS to remote UE) 

SCC-AS sends SIP re-INVITE request to the remote UE. 
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Table A.1 2.2-5 SIP INVITE request (SCC-AS to remote UE) 



INVITE sip :user3_public3@home3 .net SIP/2.0 
Via : 

To: sip : user3_public3@home3 . net ; tag = 66666 
From: sip : scc-as@homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 
t = 

m=audio 1300 RTP/AVP 96 97 
c=IN IP4 123 .45.67.89 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone -event 
a=maxptime : 2 

m=video 1302 RTP/AVP 98 99 
C=IN IP4 145 .23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



15-16. SIP 200 (OK) response (from remote UE to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending SIP 200 (OK) response to SCC-AS. 

Table A.1 2.2-6 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To: 

From: 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user3_public3@home3 . net 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123 . 112 .67.87 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



17-18. SIP ACK request (from SCC-AS to remote UE) 

SCC-AS sends SIP ACK request to the remote UE. 
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19-20. SIP ACK request (from SCC-AS to controllee UE; UE-2) 

SCC- AS sends SIP ACK request to the remote UE. 
21-22. SIP re-INVITE request (from SCC-AS to controller UE; UE-1) 

SCC-AS sends SIP re-INVITE request to the controller UE. 

Table A.1 2.2-7 SIP INVITE request (SCC-AS to UE-1) 



INVITE sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91ewxyz SIP/2.0 

Via: 

To: 

From : 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 2000 RTP/AVP 96 97 

b=AS:25.4 

a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 2 

m=video RTP/AVP 98 99 

a=sendonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23-24. SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE acknowledges the SIP re-INVITE request by sending SIP 200 (OK) response to SCC-AS. 
25-26. SIP ACK request (from SCC-AS to UE-1) 

SCC-AS sends SIP ACK request to the controllel UE, UE-1 in response to the SIP 200 (OK) response. 

27-28. SIP NOTIFY request (from SCC-AS to conroller UE, UE-1) 

SCC-AS sends SIP NOTIFY request to controller UE, UE-1 to inform about the success status if the inter-UE 
transfer. 
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Table A.1 2.2-8 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2.0 
Via : 

To: sip : userl_publicl@homel . net ; tag=24680 

From : sip : interUEtransf erOsccasl . homel . net ; tag=13 579 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

v=0 
s = - 

m=audio RTP/AVP 97 
m=video 1302 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



29-30. SIP 200 (OK) response (from controller UE to SCC-AS) 

The remote UE acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC-AS. 

A.1 2.3 Controller UE initiated media transfer from controllee UE to 
another controllee UE with subscription to dialog events 

The signalling flow in figure A. 12.3 describes the procedures for media transfer from one controllee UE to another 
controllee UE to another controllee with presistant subscription to dialog event. 

NOTE 1 : For brevity not all SIP NOTIFY requests sent as a result of the subscription to the dialog event package 
are shown. 
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UE-1 



UE-2 



UE-3 



IMS CN 



SCC AS 



UE- 
remote 



-(Audio 1, Audio 2)- 



-1. SUBSCRIBE- 

4. 200 OK 



-6. NOTIFY- 
-7. 200 OK- 
-9. REFER- 



-12. 202 ACCEPTED- 
14. NOTIFY 

15. 200 OK 



-18. INVITE- 
-19. 200 OK- 
—22. ACK— 



-24. Re-INVITE- 
— 25. 200 OK — 
28. ACK 



-36. NOTIFY- 
-37. 200 OK- 



-40. Re-INVITE- 
— 41. 200 OK — 
44. ACK 



M — 46. Re-INVITE- 

47. 200 OK — 

-4 50. ACK 



-52. NOTIFY- 
-53. 200 OK- 



(Video). 
-2. SUBSCRIBE- 

3. 200 OK 



-5. NOTIFY- 

-8. 200 OK- 



-10. REFER- 



»1 1 . 202 ACCEPTED— 

« 13. NOTIFY 

16. 200 OK 

I 17. INVITE 



-20. 200 OK- 
—21 . ACK— 



-23. Re-INVITE- 
— 26. 200 OK— 
27. ACK 



-29. Re-INVITE- 



-30. Re-INVITE- 

I 



-31. 200 OK- 



-32. 200 OK- 
—33. ACK— 



—35. NOTIFY — 
— 38. 200 OK — 
-39. Re-INVITE- 
— 42. 200 OK— 
43. ACK 



-45. Re-INVITE- 
— 48. 200 OK — 
49. ACK 



-51. NOTIFY- 
-54. 200 OK- 



<Audio 2)- 



34. ACK- 



-(Audio 1, Video)- 



Figure A.12.3: Controller UE transfers a media from one controllee UE to another 

controllee UE 

1-2. SIP SUBSCRIBE request (from controller UE to SCC-AS) - see example in table A.12.3-1 

In order that the controller UE fetches the information about the session descriptions of the UEs within the 
collaborative session, the controller UE subscribes to the existing dialog between the controller UE and the SCC 
AS. 
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Table A.1 2.3-1 SIP SUBSCRIBE request (controller UE to SCC-AS) 



SUBSCRIBE sip: scc-as@homel.net SIP/2.0 






Via : 






To: sip : scc-as@homel . net ; tag= 24680 






From: sip:userl publicl@homel.net; tag=13579 






Event: dialog; call-id=" cb03a0s0 9a2sdfglkj 321576 " , 


from-tag="54321' 


; to-tag="123456" ; 


include -session- description 






Call -ID: Cb03a0s0 9a2sdfglkj4903 3 3 






CSeq: 1 SUBSCRIBE 






Max-Forwards: 70 






P -Preferred- Identity : 






Require: target-dialog 






Expires: 36 






Target -dialog : cb0 3a0s0 9a2sdf glkj 3215 76 ; remote -tag= 


abcdef ; local-tag= 


123456 


Contact: sip:userl publicl@homel . net ; gr=urn : uuid : f £ 


ld4f ae-7dec-lld0- 


a765-0 0a0c91ewxyz 


CSeq: 






Allow : 






Accept : application/dialog- info+xml 






Content-Length: 







3-4. SIP 200 (OK) response (from SCC-AS to controller UE) 

The SCC AS acknowledges the SIP SUBSCRIBE request by sending SIP 200 (OK) response to the controller 
UE. 

5-6. SIP NOTIFY request (from SCC-AS to controller UE) - see example in table A.12.3-5 

The SCC AS sends SIP NOTIFY request containing SDP for the remote UE so that the controller UE has the 
current state of the media for the collaborative session. 
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Table A.1 2.3-5 SIP NOTIFY request (SCC-AS to controller UE) 



NOTIFY sip :userl_publicl@homel . net SIP/2.0 




Via : 




To: sipiuserl publicl@homel.net; tag=13579 




From: sip : scc-as@homel . net ; tag= 24680 




Cal 1 - ID : 




CSeq: 




Max- Forwards : 




P- Asserted- Identity: 




Require : 




Contact: sip: scc-as@homel.net 




Allow: 




Event : dialog 




Content-Type : application/dialog- info+xml 




Content-Length: (...) 




<?xml version=" 1 . " ?> 




<dialog- info xmlns= "urn : ietf : params : xml : ns : dialog- info" 




version= " " 




state="full" 




entity= " sip : scc-as@homel . net " > 




<dialog id="xxxx" call-id="f fafa" local-tag="dd" remote- tag= "ee" > 




<state>conf irmed</state> 




<local> 




<identity display="controllee UE" >sip : user2 publicl@homel . net</identity> 


< target >sip : user 2 public l@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO 


-a765- 


0a0c91e6bf 6</ target > 




< session- description type= " application/ sdp " > 




v=0 




o=- 1027933615 1027933615 IN IP4 123.112.67.87 




s = - 
t = 




m=audio 49174 RTP/AVP 96 97 




c=IN IP4 123.45.67.89 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=audio 44552 RTP/AVP 96 97 




c=IN IP4 123.45.67.89 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=video 1009 RTP/AVP 98 99 




c=IN IP4 123.112.67.87 




a=sendonly 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 




</session-description> 




</local> 




<remote> 




<identity display= " remote UE" >tel : +1-237- 555 -2222</identity> 




< target >sip : user2 publicl@home2 . net ; gr=urn :uuid : 2ad8950e-4 8a5-4a74 


-8d99- 


ad76cc7fc74< /target > 




<session-description type="application/sdp" > 




v=0 




o=- 1027933615 1027933615 IN IP4 123.112.67.87 




s = - 
t = 




m=audio 49174 RTP/AVP 96 97 




c= IN IP4 132.54.76.98 




b=AS:25.4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=audio 44552 RTP/AVP 96 97 




b=AS:25.4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 
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a=maxptime : 2 

c= IN IP4 132.54.76.98 

m=video 1009 RTP/AVP 98 99 

c= IN IP4 132.54.76.98 

a=sendonly 

b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 

< /sess ion- de script ion> 
< /remote > 
</dialog> 
< /dialog- info > 



7-8. SIP 200 (OK) response (from controllee UE-2 to SCC-AS) 

The controller UE-1 acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC AS. 

9-10. SIP REFER request (UE-1 to SCC-AS) - see example in table A.12.3-9 

There is an existing session with audio 1 and audio 2 between UE-2 (123.45.67.89), and remote UE 
(132.54.76.98). The video component is unidirectional from the remote UE to the controllee UE, UE-3 
(123.1 12.67.87). The Controller UE attempts to transfer audio 1 portion of this session to the controllee UE, UE- 
3. 

Table A.12.3-9 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-as@homel . net SIP/2.0 
Via : 

To: sip : scc-as@homel . net ; tag= 24680 

From: sip : userl_publicl@homel . net ; tag=13579 

Call -ID: Cb0 3a0s09a2sdfglkj 490333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P -Preferred- Identity : 

Refer- To : <sip :userl_public3@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765- 
0a0c91e6bf 6body=m%3Daudio%2 00%2 0RTP%2FAVP%2 00%0Dm%3Daudio%2 
4 9174%2 0RTP%2FAVP%2 096%0Dm%3Dvideo%2 01009%2 0RTP%2FAVP%2098%2 099> 

Require: target-dialog 

Target -dialog: cb03a0s09a2sdf glkj 3215 76 ; remote -tag=abcdef ; local- tag=123456 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91ewxyz> 

Accept: message/sipf rag 

Content-Length: 



11-12. SIP 202 (Accepted) response (from SCC AS to UE-1) 

SCC-AS sends SIP 202 (Accepted) response to controller UE-1 as response to SIP REFER request. 
13-14. SIP NOTIFY request (from SCC AS to UE-1) - see example in table A.13.3-13 

SCC-AS sends SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request results. 
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Table A.12.3-13 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To : sip : userl_publicl@homel . net ; tag=24680 
From : sip : scc-as@homel . net ; tag=13 579 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active ; expires=3600 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



15-16. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC- 
AS. 

17-18. SIP INVITE request (from SCC-AS to UE-3) - see example in table A.12.3-17 

Since the message 9-10 contain a Refer-to header field addressed to UE-3 and the URI paramaters, listing an 
audio line which is not currently supported by another controllee UE than UE-2, the SCC AS realizes the 
procedures is for transferring the media from that controllee UE (UE-2) to controllee UE (UE-3). SCC-AS sends 
SIP INVITE request to the controllee UE, UE-3, to transfer the audio media component. The SDP in the SIP 
INVITE request lists are the media lines within the collaborative session. In order to avoid UE-3 start sending 
audio to the remote UE, the SCC-AS adds an a-line to inactive in the SDP offer. 

Table A.12.3-17 SIP INVITE request (SCC-AS to UE-3) 



INVITE sip :userl_public3@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To : sip : userl_public3@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t=0 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendonly 
b=RR : 

b=RS : 0m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



19-20. SIP 200 (OK) response (from UE-3 to SCC-AS) - see example in table A.12.3-19 

The controllee UE, UE-3, acknowledges the SIP INVITE request by sending SIP 200 (OK) response to SCC-AS. 
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Table A.12.3-19 SIP 200 (OK) response (UE-3 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sipiuserl public3@homel.net; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag 


= 12486 


Call - ID : 




CSeq: 




P-Pref erred- Identity : 




Contact: sip:userl public3@homel 


. net;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123 . 112 .67.87 


s = - 

c=123 . 112 .67.87 




t = 




m=audio 3 02 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 




m=audio RTP/AVP 




m=video 1302 RTP/AVP 98 99 




a=recvonly 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 





21-22. SIP ACK request (from SCC-AS to UE-3) 

SCC-AS sends a SIP ACK request to UE-3 to acknowlege 
23-24. SIP re-INVITE request (from SCC-AS to controllee UE, UE-2) - see example in table A.12.3-23 

The SCC AS sends SIP re-INVITE request to controllee UE, UE-2 to put Audio 1 on hold. 

Table A.12.3-23 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip : userl_public2@home3 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 SIP/2.0 
Via: 

To: sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio 49174 RTP/AVP 96 97 
a=sendonly 
b=RR : 
b=RS : 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a=sendonly 
b=RR : 



25-26. SIP 200 (OK) response (from UE-2 to SCC-AS) - see example in table A.12.3-25 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending SIP 200 (OK) response to SCC-AS. 
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Table A.1 2.3-25 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sipiuserl public2@homel.net; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag 


= 12486 


Call - ID : 




CSeq: 




P-Pref erred- Identity : 




Contact: sip:userl public2@homel 


. net;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123.45.67.89 


s = - 

c=IN IP4 123.45.67.89 




t = 




m=audio 32324 RTP/AVP 96 97 




a=recvonly 




m=audio 34002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 





27-28. SIP ACK request (from SCC-AS to UE-2 ) 

SCC -AS sends a SIP ACK request to UE-2 to acknowlege 
29-30 SIP re-INVITE request (from SCC-AS to remote UE) - see example in table A.12.3-29 

SCC-AS sends SIP re-INVITE request to the remote UE. 

Table A.12.3-29 SIP INVITE request (SCC-AS to remote UE) 



INVITE sip : user2_publicl@home3 . net ; SIP/2 . 
Via: 

To : sip : user2_publicl@home2 . net ; tag=66666 
From: sip : scc-as@homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio 3 02 RTP/AVP 96 97 
c= IN IP4 123 . 112 .67.87 
a=rtpmap:0 PCMU/8000 
m=audio 34 02 RTP/AVP 96 97 
C=IN IP4 123.45.67.89 
A=rtpmap:0 PCMU/8000 
m=video 1302 RTP/AVP 98 99 
c= IN IP4 123 . 112 .67.87 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=recvonly 



31-32. SIP 200 (OK) response (from remote UE to SCC-AS) - see example in table A.12.3-31 

The remote UE acknowledges the SIP re-INVITE request by sending SIP 200 (OK) response to SCC-AS. 
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Table A.1 2.3-31 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To : 

From: 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user2_publicl@home2 . net ; 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c= IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=f mtp : 96mode- set=0 ,2,5,7; mode -change -per iod=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
a=sendonly 



33-34. SIP ACK request (from SCC-AS to remote UE) 

SCC-AS sends a SIP ACK request to the remote UE. 

35-36. SIP NOTIFY request (from SCC-AS to controller UE) - see example in table A.12.3-35 

The SCC AS sends SIP NOTIFY request containing SDP for the remote UE so that the controller UE can be 
aware about the change of state of the media for the collaborative session. 



ETSI 



3GPP TS 24.237 version 9.2.0 Release 9 1 45 ETSI TS 1 24 237 V9.2.0 (201 0-04) 



Table A.1 2.3-35 SIP NOTIFY request (SCC-AS to controller UE) 



NOTIFY sipiuserl publicl@homel.net; 




Via : 




To: sipiuserl publicl@homel.net; tag=13579 




From: sip : scc-as@homel . net ; tag= 24680 




Cal 1 - ID : 




CSeq: 




Max- Forwards : 




P- Asserted- Identity: 




Require : 




Contact: sip: scc-as@homel.net 




Allow: 




Event : dialog 




Content-Type : application/dialog- info+xml 




Content-Length: (...) 




<?xml version=" 1 . " ?> 




<dialog- info xmlns= "urn : ietf : params : xml : ns : dialog- info" 




version= " 1 " 




state="full" 




entity= " sip : scc-as@homel . net " > 




<dialog id="xxxx" call-id="f fafa" local-tag="dd" remote- tag= "ee" > 




<state>conf irmed</state> 




<local> 




<identity display="controllee UE" >sip : user2 publicl@homel . net</identity> 


< target >sip : user2 public IShomel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO 


-a765- 


0a0c91e6bf 6</ target > 




< session- description type= " application/ sdp " > 




v=0 




o=- 1027933615 1027933615 IN IP4 123.112.67.87 




s = - 
t = 




m=audio 49174 RTP/AVP 96 97 




c=IN IP4 123.45.67.89 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=f mtp : 96mode- set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=audio 44552 RTP/AVP 96 97 




c=IN IP4 123.45.67.89 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=video 1009 RTP/AVP 98 99 




c=IN IP4 123.112.67.87 




a=sendonly 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 




< /sess ion- de script ion> 




</local> 




<remote> 




<identity display=" remote UE" >tel : +1-237- 555 -2222</identity> 




< target >sip : user2 publicl@home2 . net ; gr=urn :uuid : 2ad8950e-4 8a5-4a74 


-8d99- 


ad76cc7fc74< /target > 




<session-description type="application/sdp" > 




v=0 




o=- 1027933615 1027933615 IN IP4 123.112.67.87 




s = - 
t = 




c= IN IP4 132.54.76.98 




m=audio 49174 RTP/AVP 96 97 




b=AS:25.4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=audio 44552 RTP/AVP 96 97 




b=AS:25.4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 
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a=maxptime : 2 

m=video 1009 RTP/AVP 98 99 

a=sendonly 

b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 

</session-description> 
</remote> 
</dialog> 
< /dialog- info > 



37-38. SIP 200 (OK) response (from controllee UE-2 to SCC-AS) 

The controller UE-1 acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC AS. 
39-40. SIP re-INVITE request (from SCC-AS to controllee UE, UE-2) - see example in table A.12.3-39 

SCC-AS sends SIP re_INVITE request to UE-2 to remove the audio 1 media component. 

Table A.12.3-39 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip : userl_public2@home3 . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91eSbf 6 SIP/2.0 
Via : 

To : sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio RTP/AVP 
m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 



41-42. SIP 200 (OK) response (from UE-2 to SCC-AS) - see example in table A.12.3-41 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending SIP 200 (OK) response to SCC-AS. 
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Table A.1 2.3-41 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Vis : 




To: sip : userl_public2@homel . net ; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag = 


= 12486 


Call - ID : 




CSeq: 




P- Preferred- Identity : 




Contact: sip:userl public2@homel 


net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123 .45.67.89 


s=- 

c=IN IP4 123.45.67.89 




t = 




m=audio RTP/AVP 




m=audio 34002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 





43-44. SIP ACK request (from SCC-AS to UE-2) 

SCC -AS sends a SIP ACK request to UE-2 to acknowlege 
45-46. SIP reJNVITE request (from SCC-AS to controllee UE; UE-3) - see example in table A.12.3-45 

SCC-AS sends SIP reJNVITE request to UE-3 to activate the audio 1 media component. 

Table A.12.3-45 SIP re-INVITE request (SCC-AS to UE-3) 



INVITE sip :userl_public3@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To : sip : userl_public3@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s=- 

c=IN IP4 123.112.67.87 
t = 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendrecv 
m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=sendonly 



NOTE 2: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request. 

47-48. SIP 200 (OK) response (from controllee UE; UE-3 to SCC AS) 

Controllee UE, UE-3 sends SIP 200 (OK) response to SCC AS. 
49-50. SIP ACK request (from SCC-AS to UE-3) 
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SCC- AS sends a SIP ACK request to the remote UE. 

51-52. SIP NOTIFY request (from SCC-AS to controller UE) - see example in table A.12.3-51 

The SCC AS sends SIP NOTIFY request containing SDP SIP 200 (OK) response received from the controllee 
UE; UE-3. 

Table A.12.3-51 SIP NOTIFY request (SCC-AS to controller UE) 



NOTIFY sip : userl_publicl@homel . net ; 
Via : 

To: sip :userl_publicl@homel . net ; tag=13579 
From: sip : scc-as@homel . net ; tag= 24680 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Content-Type: message/sipf rag ; version=2 . ; 
Content-Length: (...) 

SIP/2.0 200 OK 

To: sip : userl_public3@homel . net ; tag = xyzwv 
From: sip : scc-as@homel . net ; tag = 12486 
Call-ID: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=123 . 112 .67.87 
t = 

m=audio 3002 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=audio RTP/AVP 
m=video 13 02 RTP/AVP 98 99 
a=recvonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



53-54. SIP 200 (OK) response (from controller UE to SCC-AS) 

The controller UE acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC AS. 

A.12.3A Controller UE initiated media transfer from controllee UE 
to another controllee UE 

The signalling flow in figure A. 12. 3 A describes the procedures for media transfer from one controllee UE to another 
controllee UE. 
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-29. SIP 200 re- INVITE 
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— 5. SIP NOTIFY— 
-8. SIP 200 NOTIF 
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(-15. SIP re- INVITE- 

-18. SIP 200 re-INVlTEH 

I 19. SIP ACK 



-21. SIP re- INVITE- 
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23. SIP 200 re- INVITE 



24. SIP 200 re-INVlTEH 
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30. SIP 200 re-INVITE-l 

31. SIP ACK 



,„ „ lr . ,„, „ Tr . ^33. SIP re-INVITE- 
-34. SIP re- INVITE- 
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Figure A.12.3A: Controller UE transfers a media from one controllee UE to another controllee UE. 



1-2. SIP REFER request (SIP REFER request from UE-1 to SCC-AS) 

There is an existing session with audio 1 and audio 2 between UE-2 (123.45.67.89), and remote UE 
(132.54.76.98). The video component is unidirectional from the remote UE to the controllee UE, UE-3 
(123.1 12.67.87). The Controller UE attempts to transfer audio 1 portion of this session to the controllee UE, UE- 
3. 
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Table A.12.3A-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-as@homel . net SIP/2.0 
Via : 

To: sip : scc-as@homel . net ; tag= 24680 

From: sip :userl_publicl@homel . net ; tag=13579 

Call -ID: Cb0 3a0s09a2sdfglkj 490333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Refer- To : <sip :userl_public3@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- Ild0-a765- 
0a0c91e6bf 6body=m%3Daudio%2 00%2 0RTP%2FAVP%2 00%0Dm%3Daudio%2 
49174%2 0RTP%2FAVP%2096%0Dm%3Dvideo%2 01009%2 0RTP%2FAVP%2098%2 099> 

Require: target-dialog 

Target -dialog: cb03a0s09a2sdf glkj 3215 76 ; remote -tag=abcdef ; local-tag=12 34 5 6 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91ewxyz> 

Accept: message/sipf rag 

Content-Length: 



3-4. SIP 202 (Accepted) response (from SCC AS to UE-1) 

SCC-AS sends SIP 202 (Accepted) response to controller UE-1 as response to SIP REFER request. 
5-6. SIP NOTIFY request (from SCC AS to UE-1) 

SCC-AS sends SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request results. 

Table A.12.3A-2 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 

To : sip :userl_publicl@homel . net ; tag=2468 
From: sip : scc-as@homel . net ; tag=13579 
Call-ID: Cb03a0s09a2sdfglkjl2345 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip : scc-as@homel . net 
Allow: 

Event : refer 

Subscript ion- St ate : active; expires=360 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC- 
AS. 

9-10. SIP INVITE request (from SCC-AS to UE-3) 

Since the message 1-2 contain a Refer-to header field addressed to UE-3 and the URI paramaters, listing an 
audio line which is not currently supported by another controllee UE than UE-2, the SCC AS realizes the 
procedures is for transferring the media from that controllee UE (UE-2) to controllee UE (UE-3). SCC-AS sends 
SIP INVITE request to the controllee UE, UE-3, to transfer the audio media component. The SDP in the SIP 
INVITE request lists are the media lines within the collaborative session. In order to avoid UE-3 start sending 
audio to the remote UE, the SCC-AS adds an a-line to sendonly in the SDP offer. 
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Table A.12.3A-3 SIP INVITE request (SCC-AS to UE-3) 



INVITE sip : userl_public3@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91eSbf S SIP/2.0 
Via : 

To : sip : userl_public3@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendonly 
b=RR : 

b=RS : 0m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



11-12. SIP 200 (OK) response (from UE-3 to SCC-AS) 

The controllee UE, UE-3, acknowledges the SIP INVITE request by sending SIP 200 (OK) response to SCC-AS. 

Table A.12.3A-4 SIP 200 OK request (UE-3 to SCC-AS) 



SIP/2.0 200 OK 
Via : 

To: sip : userl_public3@homel . net ; tag = xyzwv 
From: sip : scc-as@homel . net ; tag = 12486 
Call-ID: 
CSeq: 

P -Preferred- Identity : 

Contact : sip : userl_public3@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=123 . 112 .67.87 
t = 

m=audio 3 02 RTP/AVP 96 97 

a=rtpmap:0 PCMU/8000 

a=recvonly 

m=audio RTP/AVP 

m=video 13 02 RTP/AVP 98 99 

a=recvonly 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



13-14. SIP ACK request(from SCC-AS to UE-3) 

SCC-AS sends a SIP ACK request to UE-3 to acknowledge. 
15-16. SIP re-INVITE request (from SCC-AS to controllee UE, UE-2) 
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The SCC AS sends SIP re-INVITE request to controllee UE, UE-2 to put Audio 1 on hold. 

Table A.12.3A-5 SIP INVITE request (SCC-AS to controllee UE, UE-2) 



INVITE sip : userl_public2@home3 . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91eSbf 6 SIP/2.0 
Via: 

To: sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
a=sendonly 
b=RR : 
b=RS : 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a=sendonly 
b=RR : 



17-18. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2 acknowledges the SIP INVITE request by sending SIP 200 (OK) response to SCC-AS. 

Table A.12.3A-6 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 
Via: 

To: sip : userl_public2@homel . net ; tag = xyzwv 
From: sip : scc-as@homel . net ; tag = 12486 
Call-ID: 
CSeq: 

P -Preferred- Identity : 

Contact : sip : userl_public2@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 

c=IN IP4 123.45.67.89 
t = 

m=audio 32324 RTP/AVP 96 97 
a=recvonly 

m=audio 34002 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a=recvonly 



19-20. SIP ACK request (from SCC-AS to UE-2) 

SCC-AS send a SIP ACK request to UE-2 to acknowledge. 
21-22. SIP re-INVITE request (from SCC-AS to remote UE) 

SCC-AS sends SIP re-INVITE request to the remote UE, UE-4. 
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Table A.12.3A-7 SIP INVITE request (SCC-AS to remote UE, UE-4) 



INVITE sip : user2_publicl@home3 . net ; SIP/2 . 
Via : 

To : sip : user2_publicl@home2 . net ; tag=66666 
From: sip : scc-as@homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio 3002 RTP/AVP 96 97 
c= IN IP4 123.112.67.87 
a=rtpmap:0 PCMU/8000 
m=audio 34 02 RTP/AVP 96 97 
C=IN IP4 123.45.67.89 
A=rtpmap:0 PCMU/8000 
m=video 1302 RTP/AVP 98 99 
c= IN IP4 123.112.67.87 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=recvonly 



23-24. SIP 200 (OK) response (from remote UE, UE-4 to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending SIP 200 (OK) response to SCC-AS. 

Table A.12.3A-8 SIP 200 OK request (UE-4 to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To: 

From: 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user2_publicl@home2 . net ; 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c= IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=f mtp : 96mode- set=0 ,2,5,7; mode -change -per iod=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
a=sendonly 
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25-26. SIP ACK request (from SCC-AS to remote UE) 

SCC- AS sends SIP ACK request to the remote UE. 
27-28. SIP re-INVITE request (from SCC-AS to controllee UE, UE-2) 

SCC-AS sends SIP re-INVITE request to UE-2 to remove the audio 1 media component. 

Table A.12.3A-9 SIP re-INVITE request (SCC-AS to UE-2) 



INVITE sip : userl_public2@home3 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 SIP/2.0 
Via: 

To: sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 
m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 



29-30, SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending SIP 200 (OK) response to SCC-AS. 



Table A.12.3A-10 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via: 




To: sip :userl_public2@homel . net ; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag 


= 12486 


Call-ID: 




CSeq: 




P -Preferred- Identity : 




Contact: sip:userl public2@homel 


. net ;gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123.45.67.89 


s = - 

c=IN IP4 123.45.67.89 




t = 




m=audio RTP/AVP 




m=audio 34 02 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 





31-32. SIP ACK request (from SCC-AS to UE-2) 

SCC-AS sends a SIP ACK request to UE-2 to acknowledge. 
33-34. SIP re-INVITE request (from SCC-AS to controllee UE, UE-3) 

SCC-AS sends a SIP re-INVITE request to UE-3 to activate the audio 1 media component. 

NOTE: The SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 
was generated by the SCC AS due to third party call cotrol to allow sending this SIP re-INVITE request. 
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Table A.12.3A-11 SIP re-INVITE request (SCC-AS to UE-3) 



INVITE sip : userl_public3@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91eSbf 6 SIP/2.0 
Via : 

To : sip : userl_public3@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendrecv 
m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=sendonly 



35-36. SIP 200 (OK) response (from controllee UE, UE-3 to SCC-AS) 

Controllee UE, UE-3 sends SIP 200 (OK) response to SCC AS. 
37-38. SIP ACK request (from SCC-AS to UE-3) 

SCC-AS sends a SIP ACK request to the remote UE. 

39-40. SIP NOTIFY request (from SCC-AS to controller UE, UE-1) 

The SCC AS sends SIP NOTIFY request containing SDP SIP 200 (OK) response received from the controllee 
UE, UE-3. 
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Table A.12.3A-12 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ; 
Via : 

To: sip : userl_publicl@homel . net ; tag=13579 
From: sip : scc-as@homel . net ; tag= 24680 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Content-Type: message/sipf rag ; version=2 . ; 
Content-Length: (...) 

SIP/2.0 200 OK 

To: sip : userl_public3@homel . net ; tag = xyzwv 
From: sip : scc-as@homel . net ; tag = 12486 
Call-ID: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=123 . 112 .67.87 
t = 

m=audio 3002 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=audio RTP/AVP 
m=video 1302 RTP/AVP 98 99 
a=recvonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



41-42. SIP 200 (OK) response (from controller UE to SCC-AS) 

The controller UE acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC-AS. 



A. 13 Signalling flows for release of collaborative session 
for inter-UE transfer 

A. 13.1 Introduction 

The signalling flows for release of Collaborative Session demonstrate how the session is released by the Controller UE 
or by the remote party UE. The following signalling flow is included: 

- subclause A. 13.2 shows an example where the Controller UE initiates release of a Collaborative Session. It 
demonstrates how the service control signalling and media path between the Controller UE and remote UE and 
the media path between the Controlee UE and the remote UE are released as a result of the session release; and 

- subclause A. 13. 3 shows an example where the remote UE initiates release of a Collaborative Session. 



A. 13.2 Controller UE releases collaborative session 

In this example, session release is initiated by the Controller UE (UE 1), which is involved in the Collaborative Session 
with UE 2 and the remote UE (UE 3). The SCC AS ensures that all Controlee UEs involved in the Collaborative 
Session receive a request for session release in order to completely release the session ongoing with the remote UE. 
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HPLMN of the originating UE 
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1 . Collaborative Session involving UE 1 and UE 2 in a dialog with UE 3. UE 1 is the Controller UE and UE 2 is the Controle 

end UE. 



UE. UE 3 is the remote 



Service control signalling— 

Media path between UE1 and UE 3- 



-2. SIP BYE- 



— 11. SIP BYE 

-12. SIP 200 (OK)- 



-15. SIP 200 (OK)- 



■Media path between UE2 and UE 3- 



-3. SIP BYE- 
-4. SIP BYE- 



-5. SIP BYE- 



-8. SIP 200 (OK)- 



-9. SIP 200 (OK)- 
—10. SIP BYE — 



-13. SIP 200 (OK)- 
-14. SIP 200 (OK)- 



— 6. SIP BYE — 
-7. SIP 200 (OK)- 



Figure A.1 3.2-1 : Release of Collaborative Session initiated by Controller UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. Collaborative Session currently exists in a dialog with UE 3 

A Collaborative Session involving UE 1 and UE 2 exists in a dialog with UE 3. Media paths exist between UE 1 
and UE 3 and between UE 2 and UE 3. In this scenario, UE 1 is the Controller UE in the Collaborative Session 
and thus maintains service control signalling with the SCC AS. 

2-3. SIP BYE request (UE 1 to SCC AS via intermediate IM CN subsystem entities) 

UE 1, acting as the Controller UE, initiates session release by sending a SIP BYE request towards the SCC AS. 
There is no Inter UE transfer specific content in the SIP BYE request. 

4-6. SIP BYE request (SCC AS to UE 3 via intermediate IM CN subsystem entities) 

The SCC AS routes the SIP BYE request to UE 3 indicating to the remote UE that that the Controller UE 
requests that the session is to be released. 

7-9. SIP 200 (OK) response (UE 3 to SCC AS via intermediate IM CN subsystem entities) 

UE 3 responds to the received SIP BYE request with a SIP 200 (OK) response. 

10-11. SIP BYE request (SCC AS to UE 2 via intermediate IM CN subsystem entities) 

The SCC AS, acting as a routing B2BUA, sends a SIP BYE request towards UE 2 to release the dialog it is 
involved in with UE 3 via the Collaborative Session. There is no Inter UE transfer specific content in the SIP 
BYE request. 
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NOTE 1: The SIP BYE request to UE 2 (step 10) can occur in parallel with the SIP BYE request to UE 3 (step 4). 

Alternatively, the SCC AS can send the SIP BYE request to UE 2 prior to sending the SIP BYE request to 
UE 3. 

12-13. SIP 200 (OK) response (UE 2 to SCC AS via intermediate IM CN subsystem entities) 

UE 2 responds to the received SIP BYE request with a SIP 200 (OK) response. 

14-15 SIP 200 (OK) response (SCC AS to UE 1 via intermediate IM CN subsystem entities) 

Upon receiving SIP 200 (OK) responses from UE 2 and UE 3, the SCC AS responds to the SIP BYE request 
from UE 1 with a SIP 200 (OK) response. 

NOTE 2: The SIP 200 (OK) response in step 14 can be sent earlier by the SCC AS in response to the SIP BYE 

request received from UE l(step 3). For example, the SCC AS can send the SIP 200 (OK) response to UE 
1 after receiving the SIP 200 (OK) response from UE 3 (step 9). 

A. 13.3 Remote UE releases collaborative session 

In this example, session release is initiated by the remote UE (UE 3). UE 1 and UE 2 are included in a Collaborative 
Session with the remote UE. The SCC AS ensures that all Controlee UEs involved in the Collaborative Session receive 
a request for session release in order to completely release the ongoing session. 
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i 



Intermediate IM 
CN subsytem 
entitities 



SCC AS 



HPLMN of the terminating UE 

"I l 1 

I l i 

Intermediate IM 
CN subsytem 
entitities 



UE-3 



1 . Collaborative Session involving UE 1 and UE 2 in a dialog with UE 3. UE 1 is the Controller UE and UE 2 is the Controlee UE. UE 3 is the remote 

end UE. 



Service control signalling— 

Media path between UE1 and UE 3- 



-6. SIP BYE- 



-8. SIP BYE- 



-9. SIP 200 (OK)- 



-11. SIP 200 (OK)- 



■Media path between UE2 and UE 3- 



-3. SIP BYE- 



-4. SIP BYE- 



-5. SIP BYE- 



-7. SIP BYE- 



-10. SIP 200 (OK)- 



-12. SIP 200 (OK)- 



-13. SIP 200 (OK) — 
14. SIP 200 (OK)- 



-2. SIP BYE- 



-15. SIP 200 (OK)- 

Figure A.13.3-1 : Release of Collaborative Session initiated by remote UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
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1. Collaborative Session currently exists in a dialog with UE 3 

A Collaborative Session involving UE 1 and UE 2 exists in a dialog with UE 3. Media paths exist between UE 1 
and UE 3 and between UE 2 and UE 3. In this scenario, UE 1 is the Controller UE in the Collaborative Session 
and thus maintains service control signalling with the SCC AS. 

2-4. SIP BYE request (UE 3 to SCC AS via intermediate IM CN subsystem entities) 

The remote UE, UE 3, initiates session release by sending a SIP BYE request towards the Controller UE via the 
SCC AS serving the Controller UE. There is no Inter UE transfer specific content in the SIP BYE request. 

5-6. SIP BYE request (SCC AS to UE 1 via intermediate IM CN subsystem entities) 

The SCC AS routes the SIP BYE request to UE 1, indicating to UE 1 that the remote UE requests that the 
session is to be released. 

7-8. SIP BYE request (SCC AS to UE 2 via intermediate IM CN subsystem entities) 

The SCC AS, acting as a routing B2BUA sends a SIP BYE request to UE 2 to release the dialog it is involved in 
with UE 3 via the Collaborative Session. There is no Inter UE transfer specific content in the SIP BYE request. 

NOTE 1: Step 7 can occur in parallel with step 5. Alternatively, step 7 can occur prior to step 5. The order in which 
the SCC AS sends the SIP BYE requests is not considered to be important. 

9-10. SIP 200 (OK) response (UE 1 to SCC AS via intermediate IM CN subsystems entities) 

UE 1 responds to the received SIP BYE request with a SIP 200 (OK) response. 
NOTE 2: Step 9 can occur immediately after UE1 has received the SIP BYE request in step 6. 
11-12. SIP 200 (OK) response (UE 2 to SCC AS via intermediate IM CN subsystems entities) 

UE 2 responds to the received SIP BYE request with a SIP 200 (OK) response. 

13-15. SIP 200 (OK) response (SCC AS to UE 3 via intermediate IM CN subsystem entities) 

Upon receiving SIP 200 (OK) responses from UE 1 and UE 2, the SCC AS responds to the SIP BYE request 
from UE 3 with a SIP 200 (OK) response. 

NOTE 3: Step 13 can occur after the SCC AS has received the SIP BYE request step 4 since it is not necessary to 
wait for SIP BYE requests from UE1 and UE2. 



A.14 Signalling flows for media adding/deleting within 
collaborative session for inter-UE transfer 

A. 14.1 Introduction 

This subclause shows signalling flows for adding and releasing of mediacomponent by the controller UE. Four different 
scenarios are considered in this subclause: 

scenario where the controller UE adds a new media component on a controllee UE. The procedures in this 
subclause are the same as the procedures described in subclause A. 12.3 with the exception that upon the receipt 
of a SIP REFER request from the controller UE, the SCC AS generates a SIP re-INVITE request within the 
dialog to the controllee UE instead of a SIP INVITE request; 

- scenario where the controller UE releases a media component from the controller UE, see subclause A. 14.2.1; 

- scenario where the controller UE releases a media component from the controllee UE, see subclause A. 14.2.2.1; 
and 

scenario where the controller UE releases a media component from the controllee UE and that causes the 
termination of the collaborative session, see subclause A. 14.2.2.2. 
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A. 14.2 Controller UE releases media 



A.1 4.2.1 Controller UE releases media flow on controller UE 




1. re-INVITE 
Media-A=0 ' 



10. 200 (OK) 
-c= Remote UE- 
Media-A=0 



11.ACK- 



2. re-INVITE_ 
Media-A=0 

3. re-INVITE 
c=UE-1 

- Media-A=0 - 
c=UE-2 
Media-B 



6. 200 OK 
c=UE-1 
-Media-A=0 
c=UE-2 
Media-B 

— 7.ACK — 



4. re-INVITE 

c=UE-1 
- Media-A=0 - 
c=UE-2 
Media-B 
I 

5. 200 OK 
c=UE-1 
-Media-A=0— 
c=UE-2 
Media-B 



-8.ACK- 



9. 200 (OK) 
-c=Remote UE- 
Media-A=0 



-12.ACK- 



■Collabarative session control 1 

^ Media-B between UE-2 and Remote UE- 



Figure A.1 4.2.1 : Controller UE releases media flow on controller UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2 with video (Media B) media flows. Subsequently, the UE-1 (controller 
UE) removes the media A flow that is active on the remote UE. 

1. SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities)- see example in table A.14.2.1-1 

UE-1 sends a SIP re-INVITE request towards the remote UE indicating Media A is to be removed in the SDP 
offer. 
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Table A.14.2.1-1: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip :userR_public@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91e6bf 6 > SIP/2.0 
Via : SIP/2 . 0/UDP [3 33 3 : : eee : f f f : aaa :bbb] : 13 5 7 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . visitedl . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 

c=8642; port-s=7531 
Contact : <sip : userl_public@homel . net > ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765- 

0a0c6 7t 6br4 > ; +g . 3gpp . iut -controller 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 3 33 3 : : aaa : bbb : ccc : ddd 
s = - 
t = 

m=audio RTP/AVP 97 

c=IN IP6 3333 :: aaa :bbb : ccc :ddd 

a=rtpmap:97 PCMU/8000 

m=video RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



2. SIP re-INVITE request 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS according to 
standard IMS procedure. 

3. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.1-3 

The SCC AS sends a SIP re-INVITE request with all the media information at the remote UE, sets the port 
number for media A to 0, and forwards it towards the remote UE through the intermediate IM CN subsystem 
entities. 
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Table A.14.2.1-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip :userR_public2@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91eSbf 6> IP/2.0 
Via: SIP/2. 0/UDP sccasl .homel . net ;branch=z9hG4bK240f 34 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 
From : 
To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 

c=8S42; port-s=7531 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Length: (...) 
v=0 

o = - 2987933615 2987933615 IN IP6 3333 : : aaa : bbb : ccc : ddd 
s = - 

t=o o 

m=audio RTP/AVP 97 

c=IN IP6 3333 :: aaa :bbb : ccc :ddd 

a=rtpmap:97 MPV/90000 

m=video 8888 RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the remote UE according to 
standard IMS procedure. 

5. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.1-5 

The remote UE sends a SIP 200 (OK) response with an SDP answer. 

Table A.14.2.1-5: SIP 200 (OK) response (remote UE to IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=dahtadf z4radgs . 12 , SIP/2. 0/UDP 
scscf 2 .homel .net ; branch=hsdf ldf 343 . 12 , SIP/2 . 0/UDP 
scscf 1 .homel .net ;branch=hsdf ldf 56322cc . 13 , SIP/2 . 0/UDP 
sccasl . homel . net ; branch=z9hG4bKnas34r2 . 2 1 

From: 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio RTP/AVP 97 
a=rtpmap:97 MPV/90000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 
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6. SIP 200 (OK) response 

7. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends a SIP ACK request to the remote UE through the intermediate IM CN subsystem entities. 

8. SIP ACK request (intermediate IM CN subsystem entities to remote UE) 

9-10. SIP 200 (OK) response (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response with an SDP answer indicating that Media-A has been removed 
11-12. SIP ACK request (controller UE to SCC AS) 
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A. 14.2.2 Controller UE releases media flow on controllee UE 
A. 14.2.2.1 Controller UE removes media at the controllee UE 
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Intermediate 
IM CN entities 
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a=sendonly 
b=RR:0 
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-13. re-INVITE 
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NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

Figure A.14.2.2.1 Controller UE remove media at the controllee UE 

1-2. SIP REFER request (controller UE to intermediate IM CN subsystem entities) - see example in 
table A. 14.2. 1-1 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia 
session on his device UE-1 with a voice (Media A) and UE-2(Controllee UE) with a video (Media B) media 
flows and a voice (Media C) media flow. The controller UE wants to remove the video media (Media B) 
component on the controllee UE. 

Table A.1 4.2.2.1-1 SIP REFER request (UE-1 to SCC AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 
Via: 

To : sip : interUEtransf er@sccasl . homel . net 
From: sip :userl_publicl@homel . net ; tag =13579 
Call -ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 93809824 REFER 
Max-Forwards: 70 

P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net > 

Refer- To : <sip : user2_public2@home2 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a762 - 0a0c91e6bf 6 ? 

body=m%3Daudio%2 00%2 0RTP%2FAVP%2 097%0Dm%3Daudio%2 04568%2 0RTP%2FAVP%2 097%0Dm%3Dvideo%2 00%2 0R 

TP%2FAVP%2 098> 
Require: target-dialog 

Target -dialog: cb03a0s09a2sdf glkj 13 5 79 ; to- tag=abcdef ; f rom-tag=123456 
Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91ewxyz> ; +g . 3gpp . iut -controller 
Allow : 

Accept: message/sipf rag 
Content-Length: 

3-4. SIP 202 (Accepted) response 

The SCC- AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities)-see example 
in table A.14.2.1-5 

The SCC- AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.1 4.2.2.1 -5 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91ewxyz SIP/2.0 
Via: 

To : sip :userl_publicl@homel . net ; tag=13579 

From : sip : interUEtransf er@sccasl . homel . net ; tag=22 55 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active; expires=360 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC AS. 

9-10. SIP UPDATE request (SCC AS to remote UE through intermediate IM CN subsystem entities) - see 
example in table A.14.2.2.2-9. 
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The SCC AS prepares the removal of the media component received by the controllee UE-2 and sent by the 
remote UE. 



Table A.14.2.2.2-9: SIP UPDATE request (SCC AS to remote UE through intermediate IM CN 

subsystem entities) 



UPDATE sip:UserR publicl@homel . net ; gr=urn :uuid 


f 81d4f ae-7dec- 


Ild0-a762 


-00a0c91e6bf 6 SIP/2.0 


Via : 








To : 








From : 








Call-ID: 








Cseq : 








Contact: <sip: userl publicshomel . net> ; gr=urn 


uuid: f 81d4fae- 


7dec-lld0 


-a765-00a0c67t6br4> 


Allow: 








Content-Type: application/sdp 








Content-Length: (...) 








v=0 








o = - 2987933615 2987933615 IN IP6 3333 : : aaa : bbb 


ccc : ddd 






s = - 
t = 








m=audio 6666 RTP/AVP 97 








c=IN IP6 3333 :: aaa: bbb: ccc:ddd 








a=rtpmap:97 PCMU/8000 








m=video 6668 RTP/AVP 98 








a=sendonly 








b=RR: 








b=RS : 








c=145 .23.77.88 








b=AS : 75 








a=rtpmap:98 H263 








a=fmtp:98 prof ile-level-id=0 









11-12. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-11. 

Remote UE send a SIP 200 (OK) response with SDP answer. 
Table A.14.2.2.2-11 SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: 

To: 

From: 

Call-ID: 

Cseq : 

Contact : <sip : userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a762 - 0a0c91e6bf 6 > 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5 5 5 5 : : aaa : bbb : : ccc : ddd 
s = - 
t = 

m=audio 4444 RTP/AVP 97 

c = IN IP6 5555: : aaa: bbb: : ccc: ddd 

a=rtpmap:9777 PCMU/8000 

m=video 6666 RTP/AVP 98 

a=recvonly 

b=RR : 

b=RS : 

c=145.23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



13. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.1-13 
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The SCC AS sends a SIP re-INVITE request towards the Controllee UE (UE-2). 

Table A.1 4.2.2.1 -13 SIP re-INVITE request (SCC-AS to IM CN subsystem entities) 



INVITE sip :user2_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a7S5-00a0c91e6bf 6 SIP/2.0 

Via: 

Route : 

To : sip : user2_publicl@homel . net ; abedef 

From: sip :user3_public3@home3 . net ; tag=1234 56 

Call-ID: 

CSeq: 

Max- Forwards : 
Require : 

Ref erred-By : sip : userl_publicl@homel . net 

Contact : sip : user3_public3@home3 . net ;gr=urn : uuid : f 81d4f ae-17oct-llal-a678-0054c91eabcd 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio RTP/AVP 97 
m=audio 4568 RTP/AVP 97 
c=123 . 112 .67.87 
b=AS : 75 

a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=sendonly 



14. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

15-16. SIP 200 (OK) response (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

17-18. SIP ACK request (from SCC-AS to UE-2) 

19. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2-19 

The SCC AS sends a SIP re-INVITE request with all the media information at the remote UE, set the port 
number for media B to 0, and forwards it to the remote UE through the intermediate IM CN subsystem entities. 
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Table A.14.2.2.1-19: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-0 0a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip :userl_publicl@homel . net> 
Privacy: none 
From: 
To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c67t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
Content-Length: ( . . ) 

v=0 

o = - 2987933615 2987933615 IN IP6 3 3 3 3 : : aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 3333 : : aaa: bbb: ccc: ddd 
t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=audio 4567 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SIP re-INVITE request (intermediate IM CN subsystem entities to remote UE) 

21. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.1-21 

The remote UE sends a SIP 200 (OK) response with an SDP answer. 
Table A.1 4.2.2.1 -21 SIP 200 (OK) (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=343asdf aredf atz . 12 , SIP/2. 0/UDP 

scscf 2 .homel .net ;branch=f sc35avhthaz4 .22 , SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=f sc35avhthaz4 . 12 , SIP/2 . 0/UDP 

sccasl . homel . net ; branch=z9hG4bKnas34r2 . 14 
From : 
To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa : bbb :: ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: : ccc: ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:9777 PCMU/8000 
m=audio 4545 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



22. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
23-24. SIP ACK request (SCC AS to remote UE) 

25-26. SIP UPDATE request (SCC AS to UE-2 through intermediate IM CN subsystem entities) 
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SCC AS sends a SIP UPDATE request towards Controllee UE (UE-2). 

Table A.1 4.2.2.1 -25 SIP UPDATE request (SCC-AS to UE-2) 



UPDATE sip :user2_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a7S5-00a0c91e6bf 6 SIP/2.0 

Via: 

Route : 

To : sip : user2_publicl@homel . net ; abedef 

From: sip :user3_public3@home3 . net ; tag=1234 56 

Call-ID: 

CSeq: 

Max- Forwards : 

Contact : sip : user3_public3@home3 . net ;gr=urn : uuid : f 81d4f ae-17oct-llal-a678-0054c91eabcd 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio RTP/AVP 97 
m=audio 4568 RTP/AVP 97 
c=123 . 112 .67.87 
b=AS : 75 

a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 



27-28. SIP 200 (OK) response (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

29-30. SIP NOTIFY request (SCC-AS to UE-l)-see example table A.14.2.2.1-21 

The SCC AS sends a SIP NOTIFY request to the controller UE, UE-1 to inform about the success status of the 
inter-UE transfer. 

Table A.1 4.2-2.1 -29 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip : user l_publicl@homel . net ;gr=urn:uuid : f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2.0 
Via : 

To: sip :userl_publicl@homel . net ; tag = 13579 

From : sip : interUEtransf erOsccasl . homel . net ; tag=22 5 5 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact: sip: scc-as@homel.net 
Allow : 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

v=0 
s = - 

m=audio 3434 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=sendonly 



31-32. SIP 200 OK response (UE-1 to SCC AS) 

The controller UE,UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 OK response to the SCC 
AS. 
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A. 14.2.2.2 Controller UE remove the controllee UE from the collaborative session 
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Figure A.14.2.2.2:Controller UE remove the controllee UE from the collaborative session 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1-2. SIP REFER request (controller UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-1 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia 
session on his device UE-1 with a voice (Media A) and UE-2(Controllee UE) with a video (Media B) media 
flow. The controller UE wants to remove the controllee UE from the collaborative session. 

Table A.14.2.2.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 
Via: 

To : sip : interUEtransf er@sccasl . homel . net 

From: sip : userl_publicl@homel . net ; tag = 13579 

Call- ID: Cb03a0s09a2sdfglkj49033 3 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P -Preferred- Identity : 

Refer- To : <sip :user2_public2@home2 . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a762 - 

00a0c91e6bf 6 ; method=BYE> 
Require: target-dialog 

Target-dialog: cb03a0s09a2sdf glkj 13 579 ; to-tag=abcdef ; f rom-tag=123456 

Contact: sip :userl_publicl@homel . net ; +g . 3gpp . iut-controller 

Allow: 

Accept : 

Content-Type : 

Content-Length : 



3-4. SIP 202 (Accepted) response 

The SCC AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities) - see example 
in table A.14.2.2.2-5 

The SCC AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.14.2.2.2-5 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY 
Via: 

To : sip :userl_publicl@homel . net ; tag=13579 

From : sip : interUEtransf er@sccasl . homel . net ; tag=22 55 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active; expires=36 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (UE-1 to SCC AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) to the SCC AS. 

9-10. SIP UPDATE request (SCC AS to remote UE through intermediate IM CN subsystem entities) - see 
example in table A.14.2.2.2-9. 



ETSI 



3GPP TS 24.237 version 9.2.0 Release 9 



173 



ETSI TS 124 237 V9.2.0 (2010-04) 



The SCC AS prepares the removal of the controllee UE-2 from the collaborative session by stopping the media 
received by the controllee UE-2 and sent by the remote UE. 



Table A.14.2.2.2-9: SIP UPDATE request (SCC AS to Remote UE through intermediate IM CN 

subsystem entities) 



UPDATE sip:UserR publicl@homel . net ; gr=urn :uuid 


f 81d4f ae-7dec- 


Ild0-a762 


-00a0c91e6bf 6 SIP/2.0 


Via : 








To : 








From : 








Call-ID: 








Cseq : 








Contact: <sip: userl publicshomel . net> ; gr=urn 


uuid: f 81d4fae- 


7dec-lld0 


-a765-00a0c67t6br4> 


Allow: 








Content-Type: application/sdp 








Content-Length: (...) 








v=0 








o = - 2987933615 2987933615 IN IP6 3333 : : aaa : bbb 


ccc : ddd 






s = - 
t = 








m=audio 6666 RTP/AVP 97 








c=IN IP6 3333 :: aaa: bbb: ccc:ddd 








a=rtpmap:97 PCMU/8000 








m=video 6668 RTP/AVP 98 








a=sendonly 








b=RR: 








b=RS : 








c=145 .23.77.88 








b=AS : 75 








a=rtpmap:98 H263 








a=fmtp:98 prof ile-level-id=0 









11-12. SIP 200 (OK) response (Remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-11. 

Remote UE sends a SIP 200 (OK) response with SDP answer. 
Table A.14.2.2.2-11 SIP 200 (OK) response (Remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: 

To: 

From: 

Call-ID: 

Cseq : 

Contact : <sip : userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a762 - 0a0c91e6bf 6 > 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5 5 5 5 : : aaa : bbb : : ccc : ddd 
s = - 
t = 

m=audio 4444 RTP/AVP 97 

c = IN IP6 5555: : aaa: bbb: : ccc: ddd 

a=rtpmap:9777 PCMU/8000 

m=video 6666 RTP/AVP 98 

a=recvonly 

b=RR : 

b=RS : 

c=145.23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



13-14. SIP BYE request (SCC AS to UE-2 through intermediate IM CN subsystem entities) 

The SCC AS sends a SIP BYE request towards the controllee UE (UE-2). 
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15-16. SIP 200 (OK) response (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

17. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-17 

The SCC AS sends a SIP re-INVITE request with all the media information at the remote UE, set the port 
number for media B to 0, and forwards it to the remote UE through the intermediate IM CN subsystem entities. 

Table A.14.2.2.2-17: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-0 0a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ; branch=z9hG4bKnas34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net > 

P -Access -Network- Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8642; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c67t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp, application/3gpp- ims+xml 
Content-Length: 

v=0 

o = - 2987933615 2987933615 IN IP6 3 3 3 3 : : aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 3333: : aaa: bbb: ccc: ddd 
t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



18. SIP re-INVITE request (intermediate IM CN subsystem entities to remote UE) 

19. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-19 

The remote UE sends a SIP 200 (OK) response with SDP answer. 
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Table A.1 4.2.2.2-1 9 SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=343asdf aredf atz . 12 , SIP/2. 0/UDP 

scscf 2 .homel .net ;branch=f sc35avhthaz4 .22 , SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=f sc35avhthaz4 . 12 , SIP/2 . 0/UDP 

sccasl . homel . net ; branch=z9hG4bKnas34r2 . 14 
From: 
To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5555 : : aaa : bbb : : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa : bbb :: ccc : ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap : 9777 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
21-22. SIP ACK request (SCC AS to remote party) 

23-24. SIP NOTIFY request (SCC-AS to UE-l)-see example in table A.14.2.2.2-25 

The SCC-AS sends a SIP NOTIFY request to the controller UE, UE-1 to inform about the success status of the 
inter-UE transfer. 

Table A.1 4.2.2.2-23 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via: 

To: sip :userl_publicl@homel . net ; tag = 13579 

From : sip : interUEtransf erOsccasl . homel . net ; tag=22 55 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow : 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 



25-26. SIP 200 OK response (UE-1 to SCC-AS) 

The controller UE,UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC 
AS. 
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A. 14.4 Controllee UE releases media 
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Figure A.14.4: Controllee UE releases media 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

It is assumed that UE-1 is controller UE having collaborative session control, a user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2(Controllee UE) video (Media B) media flows. Subsequently, the UE-2 
(Controllee UE) removes the media B flow that is active on the remote UE. 

1-2. SIP re-INVITE request (UE-2 to SCC AS through IM CN subsystem entities) 

A UE-2 wants to release media B active on the remote UE. For this purpose the UE-2 sends a SIP re-INVITE 
request to the SCC AS through the IM CN subsystem entities. 

3. SIP re-INVITE request (from SCC-AS to intermediate IM CN subsystem entities) - see example in 
table A.14.4-3 

The SCC AS sends SIP re-INVITE request to controller UE, UE-1 to inform that the controllee UE wants to 
release one media, and SCC AS would like to add this media back to the controller UE. 
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Table A.14.4-3: SIP re-INVITE request (SCC AS to controller UE) 



INVITE <sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-0 0a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : user3_public3@home3 . net > 
Privacy: none 
From: 
To : 

Call-ID: 

Cseq: 127 INVITE 
Require : 

Contact: <sip: user3_public3@home3 . net> ; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE , SUBSCRIBE, NOTIFY 
Content-type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 3 3 3 3 : : aaa : bbb : ccc : ddd 

s=- 

t = 

m=audio 5555 RTP/AVP 97 

c=IN IP6 3333 :: aaa :bbb : ccc :ddd 

a=rtpmap:97 PCMU/90000 

m=video 3000 RTP/AVP 98 

c=IN IP6 4444 :: aaa :bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request (intermediate IM CN subsystem entities to controller UE, UE-1) 

5. SIP 200 (OK) response (controller UE, UE-1 to intermediate IM CN subsystem entities) - see example in 
table A.14.4-5 

In this case, the controller UE does not want to add this media on itself, but like to delete this media within the 
collaborative session. The controller UE cknowledges the SIP re-INVITE request by sending SIP 200 (OK) 
response to the SCC AS with the port number set to zero for this media. 

Table A.14.4-5: SIP 200 (OK) (controller UE to SCC AS) 



SIP/2.0 200 OK 
Via : 
From : 
To : 

Call-ID: 
Cseq : 

Contact: <sip: userl_publicl@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 

0a0c43 t 6br4> ; +g . 3gpp . iut -controller 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5 5 5 5 : : aaa : bbb : : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa :bbb :: ccc : ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90 



6. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
7-8.SIP ACK (SCC AS to controller UE) 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)-see example in table A.14.4-9 

The SCC AS sends a SIP re-INVITE request to update the remote leg that the media B is released. 
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Table A.14.4-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip :user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-0 0a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max- Forwards : 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "Jake" <sip : userl_publicl@homel . net> 
Privacy: none 

From : <sip :userl_publicl@homel . net > ; tag=17182 8 
To: <sip : user3_public3@home3 . net> ; tag = 66666 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip: userl_publicl@homel . net> ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c43t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
ontent-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 3333 : : aaa : bbb : ccc : ddd 
s = - 
t = 

m=audio 5555 RTP/AVP 97 

c=IN IP6 3333 :: aaa : bbb : ccc : ddd 

a=rtpmap:97 PCMU/90000 

m=video RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



10. SIP re-INVITE request (intermediate IM CN subsystem entities to remote UE) 

11. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.4-11 

The remote US sends a SIP 200 (OK) with an SDP offer containing Media A and Media B information. 
Table A.14.4-11 : SIP 200 (OK) (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact: <sip: user3_public3@home3 . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4 > 
Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5 5 5 5 : : aaa : bbb : : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: : ccc: ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90 



12. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
13-14. SIP 200 (OK) response (SCC AS to UE-2 through IM CN subsystem entities) 

The SCC AS sends a 200 (OK) response. 
15-16. SIP ACK request (controllee UE to SCC AS) 
17-18. SIP ACK request (SCC AS to remote UE) 
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A. 14.5 Controllee UE modifies media on itself 
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Figure A.14.5: Controllee UE modifies media on itself 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2 with video (Media B) media flows. Subsequently, the UE-2 (Controllee 
UE) modifies the media B flow that is active on the remote UE. 

1. SIP re-INVITE request (UE-2 to intermediate IM CN subsystem entities)- see example in table A.14.5-1 

UE-2 sends a SIP re-INVITE request towards the remote UE containing Media B using SDP offer. 
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Table A.14.5-1 : SIP re-INVITE request (UE-2 to intermediate IM CN subsystem entities) 



INVITE <sip :userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via : SIP/2 . 0/UDP [4444: : aaa : bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . visitedl . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe2" <sip : userl_public2@homel . net> 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To: Call-ID: 
Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8G42; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765 - 

00a0cG7t6br4>Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, 
NOTIFY 

Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 4444 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 
t = 

m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS according to 
standard IMS procedure. 

3. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.14.5- 

3 

The SCC AS sends a SIP re-INVITE request to the remote UE through the intermediate IM CN subsystem 
entities containing Media A and Media B information in SDP offer. 
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Table A.14.5-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl .homel . net ;branch=z9hG4bK240a48 . 12 
Max- Forwards : 70 
Route : 

P- Asserted- Identity : 
P-Access-Network-Info : 
Privacy : 
From : 
To : 

Call-ID: 
Cseq : 
Require : 
Proxy-Require : 
Supported : 
Security- Verify : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3 3 3 3 : : aaa : bbb : ccc : ddd 
s = - 
t = 

m=audio 2222 RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddda=rtpmap:97 MPV/90000 

m=video 4444 RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request (intermedia IM CN subsystem entities to remote UE) 

5. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.5-5 

The remote EU sends a an SIP 200 (OK) response with SDP answer. 
Table A.14.5-5: SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK240f 26 . 3 , SIP/2. 0/UDP 
scscf 2 .homel .net ;branch=z9hG4bK332d2 5 . 1 , SIP/2 . 0/UDP 
scscfl .homel .net ;branch=z9hG4bK33 2d2 5 . 2 , SIP/2 . 0/UDP 
sccasl .homel .net ;branch=z9hG4bK240a48 . 12 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5 5 5 5 :: aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



6. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

7-8. SIP ACK request (SCC AS to the remote UE through intermediate IM CN subsystem entities) 
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The SCC AS sends an SIP ACK request to the remote UE through the intermediate IM CN subsystem entities. 

9. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.14.5- 
9 

The SCC AS sends a SIP 200 (OK) response containing Media B information and send it to UE-2 through the 
intermediate IM CN subsystem entities. 

Table A.1 4.5-9 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP sccasl.homel.net;branch=z9hG4bK240f42.22, 

From : 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5 5 5 5 : : aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



10. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-2) 

11-12. SIP ACK request (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

UE-2 sends a SIP ACK request to the intermediate IM CN subsystem entities which is terminated by the SCC 
AS. 



A.1 4.6 Remote UE adds new media on controllee UE 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and video (Media B) media flows. Subsequently, the remote UE adds the media B 
flow. In this scenario it is assumed that the controller UE, UE-1 automatically initiates the addition of the new media on 
UE-2 (Controllee) without first alerting the user and sends a SIP REFER request prior to sending back a SIP 200 (OK) 
response to the SIP re-INVITE request. 
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Figure A.14.6: Remote UE add new media on Controllee UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SIP re-INVITE request (remote UE to intermediate IM CN subsystem entities) - see example in table 
A.14.6-1 
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The remote UE sends a SIP re-INVITE request towards the controller UE (UE-1) indicating media B is to be 
added in SDP offer. 

Table A.14.6-1 : SIP re-INVITE request (remote UE to intermediate IM CN subsystem entities) 



INVITE <sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 2 . visited2 . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 2 . homel . net ; lr> 

P-Asserted- Identity : "David Fan" <sip : user3_public3@home3 . net > 

P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8G42; port-s=7531 

Contact : <sip : user3_public3@home3 . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 0a0c6 7t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa :bbb : ccc : ddd 
t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2-4. SIP re-INVITE request 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to UE-1 via the SCC AS according 
to standard IMS procedure. 

5-6. SIP REFER request (UE-1 to SCC AS through intermediate IM CN subsystem entities) - see example 
in table A.14.6-5 

The controller UE determines to add the new media (Media B) on the controllee UE. The controller UE, UE-1 
sends a SIP REFER request to the SCC AS containing a Refer-To header field containing the GRUU of 
controllee UE, UE-2 and a body parameter containing an m line for audio set to and an m line for video with 
the port number set to the port number of the video media line from the SDP offer in the SIP re-INVITE request 
from the remote UE. The SIP REFER request also includes a Target-dialog header field containing the details of 
the dialog for the existing session between the controller UE, UE-1 and the remote UE. 
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Table A.1 4.6-5 SIP REFER request (UE-1 to SCC AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 
Via : 

To : sip : interUEtransf erOsccasl . homel . net 

From : sip : userl_publicl@homel . net ; tag=34 719 

Call -ID: Cb0 3a0s09a2sdfglkj 490333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Ref er-To : <sip : userl_public2@home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

00a0c91e6bf e?body=m%3Daudio%2 00%2 0RTP%2FAVP%2 097%0Dm%3Dvideo%2 04444%2 0RTP%2FAVP%2098> 
Require: target-dialog 

Target -dialog: cb0 3a0s0 9a2sdf glkj 490333 ; remote- tag=13 5 79 ; local- tag=24680 
Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5- 

0a0c91e6bf 6> ; +g . 3gpp . iut -controller 
Allow : 

Accept :message/sipf rag 
Content-Length: 



7-8. SIP 202 (Accepted) response 

The SCC- AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

9-10. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities)-see example 
in table A.14.3.2-5 

The SCC AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.14.3.2-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 SIP/2.0 
Via : 

To : sip : userl_publicl@homel . net ; tag=34 719 

From : sip : interUEtransf erOsccasl . homel . net ; tag=22 55 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : <sip : user3_public3@home3 . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4 > 
Allow: 

Event : refer 

Subscript ion- St ate : active ; expires=3 6 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



11-12. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to SCC 
AS. 

13-14. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities)-see example 
in table A.14.6-13 

The controller UE responds to the SIP re-INVITE request in step 4. 
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Table A.14.6-13: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 3 , SIP/2. 0/UDP 
scscf 1 .homel .net ;branch=z9hG4bK3 3 2b2 3 . 1 , SIP/2 . 0/UDP 
sccasl . homel . net ; branch=z9hG4bKnas34r4 . 12 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp ; 
Content-Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 : : aaa : bbb : ccc : ddd 
s=- 

c=IN IP6 3333 :: ccc : ddd: aaa: bbb 
t = 

m=audio 8888 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 



15-16. SIP ACK (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

17. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)-see example in table A.14.6-15 

Editor's Note: This message can be sent as soon as the SIP REFER request is received. 

The SCC AS sends a SIP INVITE request towards UE-2 through the intermediate IM CN subsystem entities 
indicating Media B information in SDP offer. 

Table A.14.6-17: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip :userl_public2@homel . net ; gr=urn : uuid : 2ad892 0e-4 8a5-4a74 - 8d99-ad76cc7f c74 SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max- Forwards : 70 

Route : <sip : termOscscf 1 . homel . net ; lr> , < sip : pcscf 1 . visitedl . net : 753 8 ; lr ; comp=sigcomp> 
P-Asserted- Identity : "John Doe" <sip : user3_public3@home3 . net> 
Privacy: none 

From : <sip : user3_public3@home3 . net > ; tag=17182 8 
To : <sip : userl_public2@homel . net > 
Call -ID: Cb03a0s09a2sdfglkj4 903 3 3 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Ref erred-By : sip : userl_publicl@homel . net 

Contact : <sip : user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0cG7t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 4444 : : bbb : aaa : ccc : ddd 
t = 

m=audio RTP/AVP 97 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



18. SIP INVITE request (intermediate IM CN subsystem entities to UE-2) 

19. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 

UE-2 responds with a SIP 200 (OK) response containing the SDP answer. 



- see example in table A.14.6-19 
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Table A.14.6-19: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 3 , SIP/2. 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 .0/UDP 

sccasl . homel . net ; branch=z9hG4bKnas34r2 . 12 
From: 

To : <sip : userl_public2@homel . net > ; tag=237674 
Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : <sip : userl_public2@homel . net ;gr=urn : uuid : 2ad892 0e-4 8a5-4a74-8d99- 
ad76cc7f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 4444 : : aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 
t = 

m=audio RTP/AVP 97 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
21-22. SIP ACK (SCC AS to UE-2 through intermediate IM CN subsystem entities) 

23. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.14.6- 
23 

In response to the SIP re-INVITE from the remote UE, the SCC AS sends a SIP 200 (OK) response containing 
the SDP answer towards the remote UE through IM CN subsystem entities, which includes Media A and Media 
B information. 

Table A.14.6-23: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG6bKnas34r4 , SIP/2. 0/UDP 
scscf 2 . visited2 .net ;branch=34qtrada3333 .22 , SIP/2 . 0/UDP 
pcscf 2 . visited2 .net ; branch=34qtrada5454 . 12 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: aaa : bbb : ccc : ddd 
s = - 
t = 

m=audio 8888 RTP/AVP 97 

c = IN IP6 3333: : ccc: ddd: aaa: bbb 

a=rtpmap:97 PCMU/8000 

m=video 6666 RTP/AVP 98 

c=IN IP6 4444 :: bbb : aaa : ccc : ddd 

a=rtpmap:98 MPV/90000 



24. SIP 200 (OK) response (intermediate IM CN subsystem entities to remote UE) 
25-26. SIP ACK (remote UE to SCC AS through intermediate IM CN subsystem entities) 
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The remote UEsends a SIP ACK request to the intermediate IM CN subsystem entities which terminated by the 
SCC AS. 

27-28. SIP NOTIFY request (from SCC AS to controller UE, UE-1) 

The SCC AS sends a SIP NOTIFY request to the controller UE, UE-1 to inform about the success status if the 
inter-UE transfer. 

Table A.14.6-27: SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 SIP/2.0 
Via: 

To : sip :userl_publicl@homel . net ; tag=34 719 

From : sip : interUEtransf erOsccasl . homel . net ; tag=22 5 5 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : <sip : user3_public3@home3 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c67t6br4 > 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

v=0 
s = - 

m=audio RTP/AVP 97 
m=video 6666 RTP/AVP 98 



29-30. SIP 200 (OK) response (from controller UE to SCC AS) 

The controller UE acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS. 
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A. 14.7 Remote UE releases media on the controller UE 




Intermediate IM 
CN entities 



SCC AS 



Collabarative session control 1 

■ 

Media-A between UE-1 and Remote UE- 



4. re-INVITE 
c= Re mote UE- 
Media-A=0 



5. 200 (OK) 
- c=UE-1 - 
Media-A=0 



Media-B between UE-1 and Remote UE — 

1. re-INVITE 

. c= Re mote UE_ 

' Media-A=0 
Media-B 

2. re-INVITE 
_c=Remote UE 

Media-A=0 
Media-B 

3. re-INVITE 
I— c= Remote UE— 

Media-A=0 



■8. ACK- 



6. 200 (OK) 
- c=UE-1 - 
Media-A=0 

— 7. ACK — 

9. 200 (OK) 

c=UE-1 
-Media-A=0- 
c=UE-2 
Media-B 



10.200 (OK) 

c=UE-1 
- Media-=0 - 
c=UE-2 
Media-B 



-11. Ack- 



-12. Ack- 



■Collabarative session control- 



i 

-Media-B between UE-2 and Remote UE- 



Remote UE 



Figure A.14.7: Remote UE releases media on the controller UE 



NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SIP re-INVITE request (Remote Party to intermediate IM CN subsystem entities) - see example in 
table A.14.7-1 

The remote UE sends a SIP re-INVITE request towards the controller UE (UE-1) indicating Media A is to be 
removed using SDP offer. If Media B is to be removed, the SIP re-INVITE request will send to controllee UE 
(UE-2). 
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Table A.1 4.7-1 : SIP re-INVITE request (Remote UE to intermediate IM CN subsystem entities) 



INVITE <sip :Userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 2 . visited2 . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 2 . homel . net ; lr> 

P-Asserted- Identity : "David Fan" <sip : userR_publicl@homel . net > 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8S42; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c67t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa :bbb : ccc : ddd 
t = 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the re-INVITE request to the SCC AS according to standard 
IMS procedures. 

3. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.14.7- 

3 

The SCC AS removes the Media B information and forwards it towards intermediate IM CN subsystem entities. 
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Table A.14.7-3: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip: userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP sccasl .homel .net ;branch=z9hG4bKnas34r4 . 12 
Max-Forwards: 70 

Route : <sip : termOscscf 2 . homel . net ; lr> 
P- Asserted- Identity : 
P-Access-Network-Info : 
Privacy : 
From : 
To : 

Call-ID: 
Cseq : 

Supported : 
Require : 
Proxy-Require : 
Security-Verify : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = 

c = IN IP6 5555: : aaa: bbb: ccc : ddd 
t = 

m=audio RTP/AVP 97 
a=rtpmap: 97 PCMU/8000 



4. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the controller UE according to 
standard IMS procedure. 

5. SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) - see example in table A.14.7-5 

UE-1 sends a SIP 200 (OK) response with an SDP answer. 

Table A.14.7-5: SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 3 , SIP/2. 0/UDP 
scscfl .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 0/UDP 
sccasl . homel . net ; branch=z9hG4bKnas34r4 . 12 

From : 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: eee : fff : aaa : bbb 
s = - 

c=IN IP6 3333 : :eee:fff :aaa:bbb 
t = 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 



6. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
7-8. SIP ACK (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

The SCC AS sends a SIP ACK request to the controller UE through the intermediate IM CN subsystem entities. 
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9. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) - see example in table A.14.7- 
9 

The SCC AS sends a SIP 200 (OK) response with an SDP answer indicating Media A is removed to the 
intermediate IM CN subsystem entities 

Table A.14.7-9: SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG6bKnas34r4 , SIP/2. 0/UDP 
scsf 2 . visited2 . net ; branch=3q5qef sdr62233 . 22 , SIP/2 . 0/UDP 
pcscf2 .visited2 . net ; branch=3q5qef sdr62245 . 12 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

From: 

To : 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 

0a0c91e6bf 6> ; +g . 3gpp . iut- controller 
Allow: 

Accept: application/sdp; 
Content-Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: aaa : bbb : ccc : ddd 
s=- 

c=IN IP6 3333 :: aaa :bbb : ccc :ddd 
t = 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
c=IN IP6 4444 :: aaa: bbb: ccc: ddd 
a=rtpmap:98 MPV/90000 



10. SIP 200 (OK) response (intermediate IM CN subsystem entities to remote UE) 

11-12. SIP ACK (remote UE to SCC AS through intermediate IM CN subsystem entities) 

The remote UE sends a SIP ACK request to UE-1 through the intermediate IM CN subsystem entities which is 
terminated by the SCC AS. 

Editor's Note: The SDP in this flow is FFS. 



A.1 5 Signalling flows for MSC server assisted mid-call feature 



A. 15.1 Introduction 

The signalling flows in the subclause demonstrate how full duplex session on hold can be transferred together with 
active full duplex session when the MSC server assisted mid-call feature is used. The following signalling flows are 
included: 

subclause A. 15.2 shows an example of CS to PS access transfer with the MSC server assisted mid-call feature. 
- subclause A.15.3 shows an example of PS to CS access transfer with the MSC server assisted mid-call feature. 
The examples assume that: 

the SC UE, the MSC Server enhanced for ICS and the SCC AS support the MSC server assisted mid-call feature; 
the SC UE does not use ICS procedures; and 

the SCC AS is allowed to use the MSC Server assisted mid-call feature according to operator policy. 
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A. 15.2 CS to PS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A. 15. 2-1, SC UE A has two ongoing sessions over CS bearer which are anchored at 
SCC AS. The active session X is with UE B, the held session Y is with UE C. The session X and session Y are two 
party sessions. The session Y contains rejected video stream and accepted audio stream. When the SC UE connects to 
an IP-CAN, it decides to transfer the sessions over the IP -CAN. 
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Figure A.15.2-1 : Signalling flow for PS-CS Access Transfer: CS to PS 
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NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing active session X with remote UE B and a held session Y with remote UE C 
The calls have been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the sessions over the new IP -CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request transferring the active session X (SC UE A to intermediate IM CN subsystem 
entities) - see example in table A.15.2-3 

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing call X. 
Table A.15.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain. xferOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max- Forwards : 70 

Route : <sip : pcscf 1 . homel . net : 7531 ; lr> , <sip: origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID : Cb03a0s09a2sdfglkj4 902 3 7 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu, norefersub 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf 6> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " ; +g . 3gpp . mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp ; application/3gpp- ims+xml , application/vnd . 3gpp . mid-call+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c=IN IP6 5555 :: aaa :bbb : ccc : ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 



Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-call feature MIME type. 

4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 
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The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re -INVITE request towards the Remote Leg. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP re-INVITE request 
contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE 
request from the UE A (Step 3). 

8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The media path of session X is using the new IP -CAN but the media path of the session Y is still using the CS 
bearer. 

18-19. SIP BYE request (SCC AS to MSC Server via intermediate EVI CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

20-22. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 

23-24. SIP 200 (OK) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the MSC Server sends a SIP 200 (OK) response over 
the old IP-CAN to the SCC AS. 

25: SIP REFER request (SCC AS to Intermediate IM CN subsystem entities) -see example in table A.15.2-25 

The SCC AS sends SIP REFER request towards UE A inside the dialog created by the message 13. 
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Table A.15.2-25: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91e6bf 6 SIP/2.0 
Via: SIP/2. 0/UDP sip : sccasl . homel . net ; branch=z9hG4bk73 lb8a 
Max-Forwards: 70 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 

From: <tel : +1-237- 555 -2222 > ; tag=aasdf gaag 

To: <sip : userl_publicl@homel . net> ; tag=171828 

Call -ID: Cb03a0s09a2sdfglkj 490237 

Cseq: 55998 REFER 

Content-Length: . . . 

Route : <sip:scscfl. homel . net ; lr> , <sip :pcscf 1 . homel .net : 7531 ; lr> 

Contact : <sip : sccasl . homel . net ; gr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Refer- To : <sip : user3_publicl@home3 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c 74 'Target - 
Dialog=a84b4c76e66 710%3Bremote-tag=6543 64 73 5%3Blocal- 

tag=192 83 01774&Require=tdialog&From=tel : +l-23 7-555-llll&To=tel : + 1 - 987 - 654 -32 lO&Content- 
Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 

%2 02 987 93362 3%2 02 987 933623%2 0IN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0As%3D- 

%0D%0Ac%3DIN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0At%3D0%2 00%0D%0Am%3Dvideo%2 00%2 0RTP%2FAVP%2 
98%0D%0Am%3Daudio%2 03456%2 0RTP%2FAVP%2 097%2 096%0D%0Ab%3DAS : 25 . 4%0D%0Aa%3Drtpmap : 97%2 0AMR%0D 
%0Aa%3Dfmtp: 97%2 0mode-set%3D0%2C2%2C5%2C7%3B%2 0mode-change- 
period%3D2%0D%0Aa%3Dmaxptime : 20%0D%0A> 
Content -Type : application/vnd . 3gpp .mid-call+xml 

<?xml version=" 1 . 0" encoding= "UTF- 8 " ? > 
<mid-call/> 



Refer-To: contains UE C contact address and the following URI header fields: 
Target-Dialog: the dialog identifier of the source access leg. 
Require: containing "tdialog" option tag 
From: contains the public user identity of the UE A 
To: contains the public user identity of the UE C 

Content-Type: containing "application/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 

26. SIP REFER request (intermediate IM CN subsystem entities to UE A) 

The SIP REFER request is forwarded towards the UE A. 

27-28. SIP 202 (Accepted) response (UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the UE A sends a SIP 202 (Accepted) response. 

29. SIP INVITE request transferring the held session Y (SC UE A to intermediate IM CN subsystem entities) 
- see example in table A.15.2-29 

The SC UE A sends an initial SIP INVITE request to request the new call replacing the existing call Y. 
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Table A.15.2-29: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip:user3_publicl@home3 . net ; gr=urn : uuid : 2ad895 0e-48a5 -4a74 - 8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . homel . net : 7531 ; lr> , <sip: origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net > 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <tel : +1-237- 555 - 1111> ; tag=171828 
To: <tel : +l-987-654-3210> 
Call-ID: asdfqweasas 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91eGbf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " ; +g . 3gpp . mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 

Target -Dialog: a84b4c76e6 6 710 ; remote-tag=6 54 3 64 73 5 ; local- tag=19283 01774 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=video RTP/AVP 98 

m=audio 3456 RTP/AVP 97 96 

b=AS : 25 . 4 

a=curr:qos loca 

a=tcap : 1 RTP/AVPF 

a=pcfg:l t=ll sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
a=sendonly 



Request-URI: contains the remote target URI as received in the Refer-To URI in the SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

SDP: All the media are offered with the sendonly directionality. 

30. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

31. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

32. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

33. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP re-INVITE request 
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contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE 
request from the UE A. 

34. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 
35-36: SIP 200 (OK) response (UE C to SCC AS via Intermediate IM CN subsystem entities) 

The UE C generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
37-38: SIP ACK request (SCC AS to UE C via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE C. 
39: SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
40: SIP 200 (OK) response (Intermediate IM CN subsystem entities to UE A) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
41-42: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
43. Media paths between UE A and UE B 

The media paths of session X and session Y are using the new IP -CAN but the the CS bearer is still not released. 
44-45. SIP BYE request (SCC AS to MSC Server via intermediate EVI CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

46-48. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 

49-50. SIP 200 (OK) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 
51. Media paths between UE A and UE B 

The media paths of session X and session Y are using the new IP-CAN. 

A.1 5.3 PS to CS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A.15.3-1, SC UE A has two ongoing sessions over PS bearer which are anchored at 
SCC AS. When both sessions were established the SC UE and the SCC AS included the g.3gpp. mid-call media feature 
tag as specified in annex C into the Contact header fields. The active session X is with UE B, the held session Y is with 
UE C. The session X and session Y are two party sessions. The session Y contains a rejected video stream and an 
accepted audio stream. When the SC UE attaches to the CS domain, it decides to transfer the sessions over the CS 
bearer without using the ICS capability. 
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Figure A.15.3-1 : Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1. SC UE A is on an active session X with UE B and a held session Y with UE C: 
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There is an ongoing IP bearer between the SC UE and the remote UE B and another IP bearer between the SC 
UE and the remote UE C. Both sessions are anchored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the sessions over the CS bearer. 

3. CC SETUP messages 
Transaction Identifier: 3 

4. SIP INVITE request transferring the active session X (MSC Server to Intermediate IM CN subsystem 
entities) -see example in table A.15.3-4 

Upon receiving the CC SETUP message the MSC Server sends a SIP INVITE request and associates the 
transaction identifier 3 with the SIP INVITE request. 

Table A.15.3-4: SIP INVITE request (MSC Server to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . homel . net ; branch=z9hG4bk731b87 
Max- Forwards : 70 

P- Asserted- Identity : <tel : +1-23 7-555 -1111> 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel : +1-237- 555 - 1111 > ; tag=17182 8 
To: <tel : +l-237-555-3333> 
Call -ID: Cb03a0s09a2sdfglkj4903 3 3 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199, norefersub 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 

00a0c91e6bf 6> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= " server" ; +g . 3gpp . mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

Accept: application/sdp; application/3gpp- ims+xml , application/vnd . 3gpp . mid-call+xml 



v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MSC Server. 

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-call feature MIME type. 
5. Evaluation of initial filter criteria 
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The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP 
INVITE request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 

9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via EVI CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to MSC Server via EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

16. CC CONNECT message (MSC Server to SC UE A) 

17. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to MSC Server) 

18-19. SIP ACK request (MSC Server to SCC AS via EVI CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 
20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearers are still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session X, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

25. Media paths between SC UE A and UE B 

The session X is transferred from PS bearer to CS bearer, but the session Y is still at the PS bearer. 

26. SIP REFER request (SCC AS to IM CN subsystem entities) -see example in table A.15.3-26 
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The SCC AS sends SIP REFER request towards MSC Server inside the dialog created by the the message 14. 
Table A.1 5.3-26: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6 SIP/2.0 
Via: SIP/2. 0/UDP sip : sccasl . homel . net ;branch=z9hG4bk731b8a 
Max-Forwards: 70 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 

To: <tel : +1-237- 555 - 1111 > ; tag=17182 8 

From: <tel : +1-237- 555 - 3333 > ; tag=sdf sdf 

Call- ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 55998 REFER 

Content-Length: 125 

Route : <sip : scscf 1 . homel . net ; lr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Contact: sip : sccasl . homel . net 

Refer- To : <sip : user3_publicl@home3 . net ; gr=urn :uuid : 2ad8 95 0e-4 8a5 -4a74 - 8d99-ad76cc7f c74 'Target - 
Dialog=ksdj f hwrklf %3Bremote-tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel : +1- 
23 7-555-llll&To=tel : +1-987 -654 -32 lO&Content -Type=applicat ion%2Fsdp&body=v%3D0%0D%0Ao%3D- 
%2 02 987933 G23%2 02 987933 623%2 0IN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0As%3D- 

%0D%0Ac%3DIN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0At%3D0%2 0%0D%0Am%3Dvideo%2 0%2 0RTP%2 FAVP%2 
98%0D%0Am%3Daudio%2 03456%2 0RTP%2FAVP%2 097%2096%0D%0Ab%3DAS:25 . 4%0D%0Aa%3Drtpmap : 9 7%2 0AMR%0D 
%0Aa%3Dfmtp: 97%2 0mode-set%3D0%2C2%2C5%2C7%3B%2 0mode-change- 
period%3D2%0D%0Aa%3Dmaxptime : 20%0D%0A> 
Content -Type : application/vnd . 3gpp .mid-call+xml 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 
<mid-call/> 



Refer-To: contains UE C contact address and the following URI header fields: 
Target-Dialog: the dialog identifier of the source access leg. 
Require: containing "tdialog" option tag 
From: contains the public user identity of the UE A 
To: contains the public user identity of the UE C 

Content-Type: containing "application/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 

27. SIP REFER request (intermediate IM CN subsystem entities to MSC Server) 

The SIP REFER request is forwarded towards the MSC Server. 

28-29. SIP 202 (Accepted) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the MSC Server sends a SIP 202 (Accepted) response. 

30. SIP INVITE request for the held session Y (MSC Server to Intermediate IM CN subsystem entities) -see 
example in table A.15.3-30 

Upon receiving the SIP REFER request the MSC Server sends a SIP INVITE request and associates the 
transaction identifier 4 with the SIP INVITE request. 
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Table A.15.3-30: SIP INVITE request (MSC Server to intermediate IM CN subsystem entities) 



INVITE sip : user3_publicl@home3 . net ; gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2.0 
Via: SIP/2. 0/UDP mscl . homel . net ; branch=z9hG4bk73 lb87 
Max-Forwards: 70 

P- Asserted- Identity : <tel : +1-23 7-555 -1111> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel : +1-237- 555 - 1111 > ; tag=17182 8 
To: <tel : +l-987-654-3210> 
Call-ID: asdfgqwerq 
Cseq: 1275 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 

00a0c91e6bf 6> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= " server" ; +g . 3gpp . mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 

Target -Dialog : ksdj f hwrklf ; remote-tag=676723565 ; local-tag=4 54184 54 
Require: tdialog 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=video RTP/AVP 98 
m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 
a=sendonly 



Request-URI: contains the remote target URI as received in the Refer-To URI in the SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

SDP: The SDP contains preconfigured set of codecs supported by the MSC Server. All the media are offered 
with the sendonly directionality. 

31. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

32. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

33. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re -INVITE request towards the Remote Leg. 

34. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE C via the 
intermediate IM CN subsystem entities. The SIP re-INVITE request contains the SDP offer that is identical to 
the SDP offer that the SCC AS received in the initial SIP INVITE request from the UE A. 
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35. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 

36. SIP 200 (OK) response (UE C to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE C has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

37. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

38-39. SIP ACK request (SCC AS to UE C via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE C. 

40. SIP 200 (OK) response (SCC AS to IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

41. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC Server) 

Intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP INVITE request to MSC 
Server. 

42-43. SIP ACK request (MSC Server to SCC AS via EVI CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 

44. Media paths between SC UE A and UE B: 

The CS bearer and PS bearers for both the sessions are established but there is still the original IP bearer for the 
held session Y. 

45-46: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session Y, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

47-48. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

49. Media paths between SC UE A and UE B 

Both sessions X and Y are transferred from PS bearer to CS bearer. 

A. 16 Signalling flows for SRVCC session transfer for IMS 
emergency session 

A. 16.1 Introduction 

The signalling flows for SRVCC session transfer for IMS emergency session demonstrate how an IMS emergency 
session is transferred from PS network to CS network using SRVCC procedure. The following signalling flow is 
included: 
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subclause A. 16.2 shows an example when a UE initiating an emergency session in IMS for the case that the UE 
is not in limited service mode ;and 

subclause A. 16.3 shows an example when the emergency session need to transfer from PS to CS using SRVCC 
procedure for the case that the UE is not in limited service mode. 



A.16.2 UE initiating an emergency session in IMS 

The signalling flows shown in figure A. 16.2-1 describes the UE initiating an IMS emergency session procedure for the 
case that the UE is not in limited service mode. The flow illustrates the anchoring of the session at the EATF. 
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Figure A.16.2-1 : Signalling flow for UE initiating an emergency session in IMS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
NOTE 2: For clarity, the SIP 180 (Ringing) response is not shown in the signalling flow. 
NOTE 3: For clarity, the precondition mechanism is not shown in the signalling flow. 
1. SIP INVITE request (UE A to P-CSCF) see example in table A.16.2-2 
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INVITE urn: service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip:pcscf.visitl. net : 7531 ; lr ; comp=sigcomp> 
P- Preferred- Identity : <sip : userl_publicl@homel . net > 

P-Access-Network-Inf o : 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From : <sip :userl_publicl@homel . net > ; tag=17182 8 

To: <urn : service : sos . fire> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Accept : application/sdp , application/3gpp- ims+xml 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91e6bf 6 > 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; insert ed- 

by= " sip : userl_publicl@homel .net" ; routing-allowed= "yes " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c= IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des: qos mandatory remote sendrcv 

a=inactive 



Contact: contains the "gr" parameter formed from an IMEI URN as specified in 3GPP TS 24.229 [2] 
2. SIP INVITE request (EATF to E-CSCF) see example in table A.16.2-3 
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INVITE urn: service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP pcscf . visitl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip:ecscf. visitl. net ; lr ; > 
Record- Route : <sip: pcscf. visitl. net ; lr> 
P- Preferred- Identity : 
P-Access-Network-Info : 
Privacy : 
From : 
To : 

Call-ID: 
Cseq : 

Supported : 
Accept : 
Require : 
Proxy-Require : 
Accept-Contact : 
P-Pref erred-Service : 
Security-Verify : 
Contact : 
Geolocation : 
Allow : 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s = 
c = 
t= 
m= 

a=curr : 
a=curr : 
a=des : 
a=des : 
a= 



3. SIP INVITE request (E-CSCF to EATF) see example in table A.16.2-4 
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INVITE urn : service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas .visitl . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
pcscf . visitl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : <sip:esccas. visitl. net ; lr ; > 

Record- Route : <sip:ecscf. visitl. net ;lr>,<sip: pcscf. visitl. net ; lr> 

P- Preferred- Identity : 

P-Access-Network-Info : 

Privacy : 

From : 

To : 

Call-ID: 
Cseq : 

Supported : 
Accept : 
Require : 
Proxy-Require : 
Accept-Contact : 
P-Pref erred-Service : 
Security-Verify : 
Contact : 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; insert ed- 

by= " sip : userl_publicl@homel .net" ; rout ing-allowed= "yes " ; used- for -rout ing 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s = 
c= 
t= 

m= 
a= 
a= 
a= 
a= 
a= 



4. EATF anchors the emergency session 

The EATF (acting as a routing B2BUA) anchors the emergency session, i.e. the EATF is inserted in the 
signalling path which invokes a 3pcc for enablement of Access Transfers 

5. SIP INVITE request (EATF to E-CSCF) see example in table A.16.2-5 

The EATF acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 
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INVITE urn: service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas . visitl . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Route : <sip:ecscf. visitl. net : 7531 ; lr ; comp=sigcomp> 

Record- Route : <sip:ecscf. visitl. net ; lr> 

P- Preferred- Identity : <sip : userl_publicl@homel . net > 

P -Access -Network- Info : 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From : <sip :userl_publicl@homel . net > ; tag=17182 8 

To: <urn : service : sos . fire > 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Accept : application/sdp , application/3gpp- ims+xml 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 > 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; insert ed-by= " 

sip : userl_publicl@homel . net "Crouting-allowed= "yes " ; used- for -rout ing 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = 

c= IN IP6 5555 :: aaa: bbb: ccc: ddd 
t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des: qos mandatory remote sendrcv 

a=inactive 



6. SIP INVITE request (E-CSCF to PSAP) 

E-CSCF routes the SIP INVITE request to the PSAP. 

7. SIP 200 (OK) response (PSAP to E-CSCF) see example in table A.16.2-6 

Table A.16.2-6: SIP 200 OK 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ecscf . visitl . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Record- Route : <sip: ecscf. visitl. net ;lr>,<sip:pcscf. visitl. net ; lr> 
Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 
To: < urn : service : sos . fire > ; tag=232456 
Call-ID: 
Cseq : 

Require: lOOrel, precondition, 199, gruu 
Contact: <sip : mgcf . visitl . net > . 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c= IN IP6 5555 :: fff : eee : ccc :ddd 
t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des : qos mandatory remote sendrcv 

a=inactive 
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8-9. SIP 200 (OK) response (E-CSCF to EATF and to E-CSCF) 

E-CSCF forwards the SIP 200 (OK) response. 
10-11. SIP 200 (OK) response (E-CSCF to UE A) see example in table A.16.2-7 

Table A.16.2-7: SIP 200 (OK) response 



SIP/2.0 200 OK 
Via : 

Max-Forwards: 65 
Record-Route : 
Privacy : 
From: 
To : 

P-Asserted-Identity : tel : 911 ; context= " +1 " 

Call-ID: 

Cseq : 

Require : 

Contact : 

Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s = 
c = 

t= 

m= 
a= 
a= 
a= 
a= 
a= 



12. SIP ACK request 

UE A responds to the 200 (OK) response with a SIP ACK request. 

A.1 6.3 Session transfer for emergency session using SRVCC 
procedure: PS-CS 

In the example in figure A. 16. 3-1, UE A (which has a valid subscription, is authenticated and authorized for PS service 
and is normal attached to the network) has an ongoing emergency session with a PSAP using a PS bearer which is 
anchored at EATF. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to 
trigger a SRVCC handover to CS access. 
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UE A 



Interworking 
Entities 



P-CSCF 



I-CSCF 



EATF 



E-CSCF 



1. UE A is on an emergency call with PSAP through PS network. Call is anchored at EATF. 



2. UE A sends measurement reports to 
E-UTRAN, and the source 
E-UTRAN decides to trigger an SRVCC 
handover to the UTRAN/GERAN 



-1. PS bearer- 



-3.INVITE(E-STN-SR)- 



-13. SIP 200 (OK) invite - 
14. SIP ACK 



18. SIP BYE- 
I 



-19. SIP 200 (OK)- 



•22a.CS bearer - 



4. SIP INVITE 
(E-STN-SR) * 



5 Remote leg Update 



12. SIP 
200 (OK) INVITE 



-15. SIP ACK« 



—10. SIP ACK*- 



-17. SIP BYE- 



-20. SIP 200 (OK> 



-22b. PS bearer- 



6. SIP 
relNVITE 



9. SIP 200 (OK) 

relNVITE 



-16. SIP BYE-*- 




7. SIP 
relNVITE*" 
( 8. SIP 200 _ 

(OK) relNVITE 



11. SIP ACK«- 



Figure A.1 6.3-1 Signalling flow for emergency session transfer using SRVCC procedure 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE A is on an active emergency session with a PSAP 

There is an ongoing IP bearer between the UE A and the remote end PSAP. The call is achored at EATF. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSC Server initiates the session transfer with the E-STN-SR, refer to 
3GPPTS 23.237 [9]. 

3. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
table A.16.3-2 
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Table A.16.3-2: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl . net ; branch=z9hG4bk731b87 
Max-Forwards: 70 

Route : <sip:icscfl. visitl. net ; lr> 

P- Asserted- Identity : <tel : +1-23 7-555 -1111> 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=visitl . net 
Privacy: none 

From: <tel : +1-23 7- 555 - 1111 > ; tag=17182 8 
To: <tel: +l-237-555-3333> 
Call -ID: Cb03a0s09a2sdfglkj4903 34 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : mscl . homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91e6bf 6 > ; +g . 3gpp . icsi- 

ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



Request-URI: contains the E-STN-SR, as routed to the EATF 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

Contact: contains the "gr" parameter formed from an IMEI URN as specified in 3 GPP TS 24.229 [2] 

4. SIP INVITE request 

The I-CSCF routes the SIP INVITE request directly to the EATF by using the procedure defined in 
3GPP TS 23.228 [15] for PSI based application Server termination. 

NOTE 2: The use of indirect routing for PSI based Application Server Termination as described in 

3GPP TS 23.228 [15] in subclause 5.7.6 cannot be used for routing the SIP INVITE request to the EATF. 

5. Remote Leg Update 

The EATF based on the content of the "gr" parameter in the Contact header field correlates the SIP INVITE 
request to the local and remote call legs of the existing session between the UE A and the remote end. The EATF 
performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

6. SIP re-INVITE request (EATF to intermediate IM CN subsystem entities) -see example in table A.16.3-3 

TheEATF acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 

Table A.16.3-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

INVITE urn : service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP esccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 68 
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Route: <sip : ecscf 1 . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function-Addresses : ccf = [5555 : :b99 : c88 : d77 : e66] ; ccf = [5555 :: a55 :b44 : c33 : d22] ; 

ecf = [5555 : : If f :2ee : 3dd:4ee] ; ecf = [5555 : : 6aa: 7bb: 8cc : 9dd] 
P -Charging- Vector : icid-value= "BzyretyU0dm+6O2IrT5tAFrbHLso=023551034 " ; orig- ioi= " type3homel .net" 
Privacy: none 

From : <sip : userl_publicl@homel . net > ; tag=17182 8 
To : <urn : service : sos . f ire> ; tag=232456 
Call- ID: Cb03a0s09a2sdfglkj 490333 
Cseq : 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 > 
Allow: 

Content-Type: Content-Length: 
v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVPF 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set = , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
m=message TCP/MSRP 98 
a=accept-types : text/plain 



7. SIP re-INVITE request (E-CSCF to PSAP) 

E-CSCF forward the SIP re-INVITE request to the PSAP. 

8. SIP 200 (OK) response (PSAP to E-CSCF) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the PSAP has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

9. SIP 200 (OK) response (E-CSCF to EATF) 

E-CSCF forward the SIP 200 (OK) response to the SIP re-INVITE request to the EATF in the originating 
network. 

10-11. SIP ACK request (EATF to PSAP via IM CN subsystem entities) 

The EATF generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to 
the PSAP. 

12-13. SIP 200 (OK) response (EATF to interworking entities via IM CN subsystem entities) 

The E- SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 
(OK) response to the interworking entities. 

14-15. SIP ACK request (interworking entities to EATF via IM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward the SIP ACK 
request to the EATF. 

16-18: SIP BYE request (EATF to UE A via intermediate IM CN subsystem entities) 

The EATF terminates the source access leg, which was using the old IP -CAN, by sending a SIP BYE request to 
the UE A. 

19-21. SIP 200 (OK) response (UE A to E- SCC AS via intermediate IM CN subsystem entities) 
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Upon receiving the SIP BYE request over the old IP -CAN, the UE A sends a SIP 200 (OK) response over the 
old IP -CAN to the EATF. Subsequently, the UE A relinquishes all resources pertaining to the old IP-CAN. 

22a. CS bearer establishment (interworking entities to UE A) 

22b. IP bearer establishment (interworking entities to PSAP) 
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Annex B (informative): 
Collaborative session state model 

This annex describes a state model applicable for the UEs involved in collaborative session handling for inter-UE 
transfer, listing possible states and state transitions. Some procedures in collaborative session handling lead to 
synchronous state transitions of two different UEs. 

Editor's note: the state model is not intended directly for implementation; rather it is provided as an abstraction and 
condensed view of what is specified in procedures in the main body of this specification 
(clauses 16 to 19). The final status and placement within this specification of contents currently 
documented in this annex is FFS. 

Figure B-l visualizes the states and state transitions for UEs within a collaborative session for inter-UE transfer. 



NULL 



transfer media (last) 
release media (last) 
collaborative session release 



modify media 
release media (non-last) 
transfer media (non-last) 
report status 



Controlled 
Mode 



- transfer media 
(all) 



monitoring 



- transfer 
media 



collaborative session release 
transfer media (all) 



transfer media (last) 
collaborative session release 



media addition 



Controlling 
Mode 



release media (last) 
transfer media 



Controlling 
Mode (with 
media) 




- monitoring 

- media modification 

- tran sfer media (non-last) 



Figure B-1 : State model for UEs in collaborative session for inter-UE transfer 

The description of the possible states of a UE within a collaborative session is given in table B-l. 



Table B-1 : States of UEs in collaborative session for inter-UE transfer 



State 


Description 


NULL 


No participation in a collaborative session. 


Controlling Mode 


The UE participates in a collaborative session and performs the role of a 
controller UE, but has no media with the remote leg established. 


Controlling Mode (with media) 


The UE participates in a collaborative session and performs the role of a 
controllling UE; it has at least one media with the remote leg established. 


Controlled Mode 


The UE participates in a collaborative session and performs the role of a 
controllee UE; it has at least one media with the remote leg established. 



ETSI 



3GPP TS 24.237 version 9.2.0 Release 9 218 ETSI TS 124 237 V9.2.0 (2010-04) 

NOTE 1 : in this release the state "Controlled Mode" without media is not possible. 

NOTE 2: the state "Controlled Mode" does not require any specific functionality for an IMS UE. 

The possible state transitions and their triggering procedures are listed in table B-2. 
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Table B-2: State transitions of UEs within collaborative session for inter-UE transfer 



Source 
state 


Target state 


State Transition 


>. i „ 
Nr. 


Description 


Coupled 
with 




Controlling 
Mode 


transfer media 
(outbound, all) 


1 


The UE transfers all media to a controllee UE, but 
keeps control of the collaborative session. 


3 


NULL 


Controlling 
Mode (with 
media) 


transfer media 
(outbound) 


2 


The UE transfers (not all) media to a controllee UE, 
and keeps control of the collaborative session. 


3 




Controlled 
Mode 


transfer media 
(inbound, first) 


3 


The UE gets media transferred from another UE, 
which keeps collaborative session control. 


1 or 2 




NULL 


transfer media 
(inbound, last) 


4 


The UE transfers from another UE the last media of 
the collaborative session back to itself. 


18 






collaborative 
session release 


5 


— i— i ■ i 1 1 i i j ■ /■ 1 1 

The session with the remote party is released (by the 
controlling UE, the NW or the remote party). 


19 


Control- 
ling Mode 


Controlling 
Mode 


monitoring 


6 


The controlling UE requests monitoring status of the 
collaborative session from one or more controllee 
UEs. 


22 




Controlling 
Mode (with 
media) 


add media 


7 


Tl x II* 1 1 I - || |" / *j.| i| i \ 

The controlling UE adds media (with the remote party) 
onto itself; other UEs and their media are not affected. 






transfer media 
(first) 


8 


— i— i i ■ f— i r i 1 /■■. r*..i\ r x" xl 

The UE transfers media (its first) from one of the 
controllee UEs back to itself. 


18 or 23 




NULL 


collaborative 
session release 


9 


See nr. 5. 


20 




transfer media 
(last) 


10 


The controlling UE transfers its last media to a 

X 11 1 1 l~~ 1 1 1 ■ ■ 1 || | _| 

controllee UE and additionally hands over 
collaborative session control. 








transfer media 
(outbound, all) 


11 


The controlling UE transfers (all) media to a controllee 
and keeps collaborative session control. 


23 


Control- 
ling Mode 
(with 
media) 


Controlling 
Mode 


release media 
(last) 


12 


The controlling UE releases its last media, but other 

1 * ■ ■ i | i | || T~ ■ i | i 1 III X* 

media remain with other UEs within the collaborative 
session. No change of collaborative session control, 
which remains with the currently controlling UE. 






monitoring 


13 


See nr. 6. 


22 




modify media 


14 


The controlling UE modifies its own media, other UEs 
and their remain unaffected. 






Controlling 
Mode (with 
media) 


transfer media 
(outbound, non- 
last) 


15 


The UE transfers media to one of the controllee UEs 

xl x 1" Ixl 1 III X" 

at least one media, and thus also collaborative 
session control remains with it. 








transfer media 
(intbound, non- 
first) 


16 


Thp I IF trpn^fprci mpdip frnm nnp nf thp rnntrnllpp 

1 1 IC \J A LI ul 1 JlCI o 1 I ICUlu IIWIII \J\ \\j \J\ LI 1 \j \j\J\ 1 LI \J\\\j\j 

UEs back to itself. 


18 or 23 




void 


void 


17 


void 








transfer media 
(outbound, last) 


18 


The controllee UE gets its last media removed by the 
controlling UE. As a consequence, the UE is no longer 
participant of the collaborative session. 


16or8 




NULL 


release media 
(last) 


19 


As nr. 1 8, but removal of media instead of transfer. 


4 






collaborative 
session release 


20 


See nr. 5. 


5 




void 


void 


21 


void 




Controlled 
Mode 




report status 


22 


The UE reports the status of is established media to 
the controlling UE. 


6 




Controlled 


transfer media 
(inbound or 
outbound, non- 
first, non-last) 


23 


The controllee gets media transferred to or from 
another UE (controlling or controllee) in the 
collaborative session, dictated by the controlling UE. 


11 




Mode 


release media 
(non-last) 


24 


Media on the UE is released, either by the UE itself or 
dictated by the controlling UE; at least one media is 
kept. 








modify media 


25 


Media on the UE is modified, either by the UE itself or 
dictated by the controlling UE; other UEs are not 
affected. 
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Annex C (normative): 

Media feature tags defined within the current document 
C.1 General 

This subclause describes the media feature tag definitions that are applicable for the 3GPP IM CN Subsystem for the 
realisation of the MSC server assisted mid-call feature and IUT transfer controller functions. 



C.2 Definition of media feature tag g.3gpp. mid-call 

Media feature-tag name: g.3gpp. mid-call 
ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN.l Identifier will need to be updated once the IANA registration is completed. 

Summary of the media feature indicated by this tag: This feature-tag when used in a SIP request or a SIP response 
indicates that the function sending the SIP message supports the MSC server assisted mid-call feature. 

Values appropriate for use with this feature-tag: none 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone supports the MSC server assisted mid-call feature 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 

C.3 Definition of media feature tag g.3gpp.iut-controller 

Media feature-tag name: g.3gpp.iut-controller 
ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN.l Identifier will need to be updated once the IANA registration is completed. 

Summary of the media feature indicated by this tag: This media feature-tag when used in a SIP request or a SIP 
response indicates that the function sending the SIP message supports the IUT Controller functionality. This media 
feature tag does not imply that the controller UE capabilities are handled in the same protocol manner. 

Values appropriate for use with this feature-tag: none 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone supports the IUT controller capability 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 
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Annex D (informative): 
XML schemas 

D.1 MSC Server assisted mid-call feature XML schema 



D.1.1 General 

This subclause defines XML schema and MIME type related to the MSC Server assisted mid-call feature. 



D.1.2 XML schema 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 
<xs : schema 

xmlns :xs = "http : //www. w3 . org/2 01/XMLSchema" 
element FormDef ault= " qualified" 
attributeFormDef ault= "unqualified" > 

<xs:element name="mid-call" type= "Tmid-call " /> 

<xs : complexType name="Tmid-call" > 
<xs : sequence> 

<xs : any namespace= " ##other " processContents = " lax" minOccurs = " " maxOc curs = " unbounded " / > 
</xs : sequence> 

<xs : anyAttribute namespace= " ##any" processContents= " lax" /> 
</xs : complexType> 

</xs : schema> 

D.1 .3 IANA registration template 

Editor's note: The MIME type "application/vnd.3gpp.mid-call+xml" as defined in this subclause is to be registered 
in the IANA registry for Application Media Types based upon the following template. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.mid-call+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21] 
Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations: 
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Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. 
Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 9.1.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 
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